Swifterswift: Why did 5.0 remove the entire SwifterSwift module?

[jeanmartin]

• [x] I've read, understood, and done my best to follow the Contributing guidelines before opening this issue.

What did you do?

Upgraded from 4.6 to 5.0

What did you expect to happen?

SwifterSwift or something similar to still exist so I can continue to use methods like screenWidth

What happened instead?

The entire module was removed without explanation. The changelog simply states "Breaking Change" without reference to a commit or an explanation.

[anonrig]

I'm facing the same exact issue. I was using several variables such as SwifterSwift.screenWidth or SwifterSwift.bundleId and now SwifterSwift doesn't include any replacements for those.

[LucianoPAlmeida]

@omaralbeik Can clarify that, but it was actually not a module but a class, what was conflicting in a way that we couldn't use the module explicitly, because the compiler infers that class with the same name of the module. In fact, I thought we had just renamed it cc @omaralbeik

[omaralbeik]

Hey @jeanmartin, thank you for your question!

As @LucianoPAlmeida mentioned SwifterSwift was a global struct, not a module and we get rid of it in v5.0 for the following two reasons

Prefer extensions in their relative types

Most of SwifterSwift methods and variables were extensions of UIApplication, Bundle, and UIDevice that lived in SwifterSwift object because at the time we didn’t see more suitable place for them. However, I believe it leads to less readable code when using them in your applications

import SwifterSwift
let width = SwifterSwift.screenWidth

// vs

let width = UIScreen.main.bounds.width

Import Conflicts

Having a global object named SwifterSwift might cause some conflicts with importing the project and various modules from it.

---

Sorry for the inconvenience, however this was not well-structured from the beginning and needed to be changed sometime, and with Swift 5.0 release I thought it is the right time :)

[anonrig]

Hey @omaralbeik

Thank you for the explanation. But unfortunately, the same reasoning doesn't apply to SwifterSwift.bundleId. Since it's longer and not that readable in the native format. As a user of SwifterSwift for some time atm, I personally prefer having these small things that decrease the pain in Swift and iOS.

[omaralbeik]

@anonrig I understand your pain, sorry for the breaking change here, as a work around, you can create a struct called SwifterSwift and add your used code to it

[ShivaHuang]

Instead of removing whole SwifterSwift.swift file suddenly, I think use @available attribute to mark these properties as deprecated and provide attribute arguments like message and renamed will help developers making a smoother transition.

[chulbert]

In the spirit of extending relevant types - with which is _strongly_ agree - this could easily be re-introduced as an extension on Bundle.

Also, while this could have arguably been phased out gradually, developers should generally expect breaking changes in major version upgrades (SwifterSwift 4 -> 5).

[omaralbeik]

I'm going to close this issue for now, feel free to open it again to extend the discussion :)