ObjC equivalents to Swift solutions #1: Avoiding ObjC class name collisions | Hacker News Reader

ObjC equivalents to Swift solutions #1: Avoiding ObjC class name collisions

penandpapersoftware.com

12 pointspenpapersw22 comments

A few days ago I downloaded a third party iOS library, written in Obj-C. It was provided as part of a paid cloud API service. After integrating it, I was amazed (horrified?) to find that the whole library had been implemented without class prefixes. There were multiple collisions with Swift classes in my project.

Surprisingly the app still compiled, but tried to use the library class definitions instead of my own. I didn't end up using the library, or continuing with the API service.

Really? That's not good. Well, as long as they're not using any kind of class-aware RPC, you can probably just add prefixes to all the classes yourself. Would take about 10 minutes using the Rename Class feature of Xcode, and it would be tedious, but it should work.

Such libraries are often closed source. Even if not, such a solution does not scale. Each update, you'd have to go through this hoop. Just vote with your wallet and do not use services that offer terrible SDK / API.

Yeah, good point. I actually started to do that, but on further inspection the library did some other questionable things too - and didn't accomplish the primary purpose very well. The whole thing seemed to be more of a 'check a box so we can say we have an iOS library' than a real attempt at reliable, usable library.

Historically, one of the key dangers with using unprefixed names has been that future system updates add new classes which collide. Testing at dev-time won't future-proof you very well.

Good point! Just updated the blog post to mention this. Ultimately I don't think it's still too big of an issue. It just means that you may need to rename your classes in the future if an OS update causes a class name collision.

System should not add unprefixed classes; this is one of the biggest sins a system framework can do, especially one from Apple and its engineers, who are aware of ObjC limitations.

Somewhat related:

In 2010 I implemented a UIView subclass for a simple stylized spinner. In the view controller that contained this spinner, I added two methods to start and stop the spinner. I called them `startSpinner` and `stopSpinner`. Our app was rejected for using “private APIs.” Finding it ridiculous that Apple would use such a common signature internally without any prefixes and actually would check for it in all third-party apps and reject them, we relented and changed our method names.

In 2015, at a new job, in a new city and working on an entirely different project, I had to implement another UI spinner. Since I’m a creature of habit, I again named the methods for starting and stopping the spinner: `startSpinner` and `stopSpinner` respectively. This time the project I was working on was an SDK so all of our clients were being rejected for using a private API, named... “startSpinner” and “stopSpinner”.

Software is hard.

>Software is hard.

More like Apple is extremely arbitrary and ham-handed with their APIs. Cocoa Touch is the most poorly designed framework I have ever dealt with in my programming career. Their insistence on keeping the libraries closed source is absolutely insane, and often leaves you needing to roll something completely custom just to change a color. The lack of a viable native alternative led me to abandon iOS development personally.

It doesn't seem very forward thinking to start a new app in whats essentially a deprecated language.

Very good point. I addressed our reasoning behind choosing Objective-C to some extent in the previous blog post[1].

A big reason behind this was to minimize the binary size, which means a much faster download.

Because we used Objective-C and didn't use any third party code, our todo-list app Accomplish[2] is only 289 KB, whereas the most similar competing app (MinimaList) is 8.8 MB and almost all the other competing apps are between 60 and 80 MB each.

It may seem like an unnecessary optimization, but we're hoping a faster download/install experience, along with close attention to detail in other ways, will give our app a competitive edge.

[1] http://penandpapersoftware.com/blog/2017-04-13-using-objc-fo...

[2] http://penandpapersoftware.com/accomplish/

For many apps, especially those that aren't AAA with a full team of dedicated engineers behind them, the constant churn of Swift major version upgrades is a pretty good argument for just sticking with Objective-C.

Swift 3 was a major breaking upgrade. Apple has already stated that 4.0 will not have large breaking changes. Swift is open source so you can follow its development.

That's nice. But until then, having to re-learn idiomatic Swift every major version, and having to comb through all of your source code to ensure it's still doing what you expect in the new version (automatic migration or not) is a lot of extra effort that you simply don't need to put in with Objective-C. And another nice bonus is that you get to shave off about 10mb of swift runtime from your .ipa.

Objective-C is not deprecated at all. It's impossible to deprecate it in the near future since it's so heavily used in frameworks at Apple that nobody with a right mind wants to rewrite.

The only thing to look forward is is ABI stability for Swift, meaning it's a grown up language and we don't need to pack the runtime with every Swift app anymore.

If you have people who know Objective-C, there's no gain in being "forward thinking" for its own sake. But if you're not playing with your own money, sure, why not spend extra development time to bring everyone up to speed on what Swift looks like this year - it won't make the app any better and will cost more, but improves the team's résumés.

I think better support and better code is a benefit, but thats just me. You sound like youve gotten rubbed in the past by this, no?

And by the way, "forward thinking" is not something you can be or do for its own sake. Think about it. That doesnt even make sense.

Don't forget the next year, when Apple yet again breaks the language and you have to take all your large codebase and convert it to Swift (x+1).

There might be a handful of changes in the future but it won't be anything like 2 to 3. I imagine that the automatic converter will get most of them. Swift is open source so you'll know all changes well in advance.

Objective-C isn’t deprecated at all. There is more chance of current valid Swift code being deprecated in a year than Objective-C. In fact, all Swift code written in its first two years of public existence is completely deprecated now. The same code, had it been written in Objective-C would be perfectly valid today.

It's not to hard to convert to Swift 3.0. Apple's converter helps a lot. I documented most of the things I had to change.

https://h4labs.wordpress.com/2016/09/17/my-ios-10-and-swift-...

That's gross oversimplification and misleading. I was recently given the source of a large iOS app belonging to a company that our company purchased. The code is very well written, just has not been maintained past Swift 2. The converter did more hard than it solved. Xcode Swift converter is only good for small projects with no advanced language use.

Reply on news.ycombinator.com