
ObjC equivalents to Swift solutions #1: Avoiding ObjC class name collisions - penpapersw
http://penandpapersoftware.com/blog/2017-04-14-objc-equivalents-to-swift-solutions-part-1-avoiding-class-name-collisions/
======
jordansmithnz
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.

~~~
penpapersw
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.

~~~
LeoNatan25
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.

------
andymatuschak
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.

~~~
mightykan
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.

~~~
aphextron
>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.

------
ruleabidinguser
It doesn't seem very forward thinking to start a _new app_ in whats
essentially a deprecated language.

~~~
pavlov
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.

~~~
LeoNatan25
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).

~~~
melling
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.

