Hacker News Reader

Comment by draw_down | Hacker News Reader

Obviously you're welcome to do what you like. But it seems how these things go with Apple is: they introduce it, and it's optional, then they build on it some (still optional), then they say "using this is a really good idea", then they say "a year from now you have to use this". And maybe not a year. So you're free to exercise your choice... for a while.

View on HN

Sometimes there is a secret master plan behind these actions, sometimes they're doing what makes the most sense. I can see how bitcode might make a lot of sense from a centralized distribution standpoint, and it may work for certain types of apps. But you still may prefer to test and experiment with the actual code that will be distributed to your customers. Seems like a reasonable requirement. Apple ought to have an extraordinarily good and transparent reason to require centralized compilation in the future.

I agree with the sentiment. However, if enough people, or Taylor Swift, decide to tell Apple to GTFO, they will back down on a retarded idea, or at least modify it to a more (but not completely) acceptable extent.

A good argument against the bitcode is the huge amount of open source libraries in C used by thousands of popular apps (such as openssl), which may not, or do not, particularly enjoy the bitcode treatment at AppStore.

Not only that, but when people's excuses for not shipping it are "Bitcode's gonna get the AppStore hacked and my apps backdoored"... they'll be more inclined to realise they know better than most of their app developers.

Any example of some other thing that went that way?

And no, the transition to 64 bit or Swift are not that.

Java-Objc bridge, requiring Xcode (people used to use Metrowerks and other tools). I don't do this for my day job so there are probably lots of others... something around ARC maybe?

OK, I though you meant some kind of evil plan, lockdown etc impossed to people by Apple progressively. That's why I said we should exclude ARC and transition to Swift. I meant in general that we shouldn't count "migration to newer technologies/frameworks" as such a thing.

If you meant, Apple imposing newer stuff to developers, then yes Apple does that.

Though, I'd say most of that is for the platform's good. Even stuff like deprecating Java -- it never got popular for OS X apps as Apple intented, the situation with SUN had changed, and keeping it going forward would be dead weight.

And Metrowerks might be good for early '00s, but not going forward with iOS, and multiple languages, and Storyboards, and all those things.

Still, the forced transition is PITA for anyone who has had a successful app on the AppStore for several years. Essentially, you are being forced making a new app every other year, just to have an app, in spite of the fact that the old one(s) work perfectly well and everyone is happy with them. In my book, that is throwing money - it's cost us half the price to keep three other competing platforms afloat.

And I find it disheartening that most developers seem so accepting of unnecessary costs to their time and health. Much like the worker class before the unions - any work conditions go. I for one am pretty tired of years of iOS-update introduced incidents and overtime work to manage new products, while juggling undue maintenance on old products. I also find it disheartening developer companies don't take a good look at costs and demand improvements, instead of accepting a steady trickle of punishment for success.

If it is for the platform's good, I wish the platform ended so we can develop for platforms that deliver better working conditions and less motivated uncertainty, fear, and doubt.

Reply on news.ycombinator.com