Hacker News Reader

Comment by dplgk | Hacker News Reader

After doing some iOS/Mac development, I'd say some bugginiess is caused by changing APIs and behaviors inflicted by Apple, expected to be absorbed/dealt with by developers. They mercilessly do this with every release and no doubt that affects their internal projects. Also, xcode has gone the way of iTunes and ObjC was always a huge pain. It's a really hostile environment to develop in, where you're having to play catch up all the time.

View on HN

Wow. My experience is opposite. Been in iOS development for over 10 years already, little less for Android. App made for iOS still works with very minor adjustments, while on Android it’s a mess. We was forced to change build system several times, breaking changes and just silly API renames, service depreciations, generations of push services, forcing firebase and AndroidX, change of permission model, of concurrency model.

Honestly, I can’t even name single such change for iOS. At worse it is adding interface implementation.

About objective c and Xcode. Just lol. I love being able to debug by pressing single button and putting breakpoint. Android studio, being abominably ugly and slow, and killing battery like in 1 hour, still struggles to do that for native code.

Also, what is wrong with Objective C?

Unfortunately, just because the developer experience on Android can be even worse, that doesn't mean the developer experience on iOS isn't bad.

Yes. Thing is this are de-facto only two platforms alive. Yes. Mobile (and desktop) developers life suck. But someone has to write all that software.

And, IMO, iOS/macOS/Cocoa/Xcode is best out there. And most importantly - most stable. Nice boutique experience, nice API, good documentation, everything is integrated and working.

Other platforms are even worse. Way worse. I am also doing Switch, KaiOS, Xbox, PS3/4, did Symbian and like dozen more obscure ones.

Pretty much this ^

All these rants about XCode/iOS/UIKit/ObjC somehow being a terrible environment to develop for are presuming there is something significantly better out there. There isn't, it seems. You will find developers bitching about literally any development platform out there (except maybe Haskell when you are on HN ;-)

My personal experience is limited to C++/ObjC/Java/Python on Linux/macOS/iOS, and I can only agree that ObjC on Apple platforms is by far the easiest and most productive environment for me. I've only dabbled in Swift a tiny bit so far, but my feeling is that it's also a lot less hostile than C++. In terms of toolkits, Cocoa/UIKit is at least as good as Qt, and much better then e.g. GTK or the abominations you have to deal with if you develop Java applications. Don't know about Windows platforms but considering the endless list of technologies and frameworks that are supposed to supersede whatever came before it, it's likely not much better over there.

Development on Windows desktop maybe dull, but pretty straight forward/stable/well documented in my opinion

It is. With microsoft it's another problem: too much technologies. All are OK-is, but ultimately deprecated. MFC, WinForms, WPF, Silverlight, you name it. But, to be clear, I think Visual Studio has close 2nd place in desktop development experience after Xcode. Also, IMO, VS is way better IDE that Xcode for generic C++ projects.

> And most importantly - most stable

I have to restart XCode at least once an hour to get all my breakpoints back and several times a day if it crashes for no apparent reason and boots up with the project missing, empty or missing files. Fortunately I don't do a lot of app development any more but some low level C libs don't compile themselves (no: not possible to do this in any other language).

Stable is not what I use to describe XCode. Bloated with "do it the apple way" yes but not stable.

Well, they said "most stable".

> I can’t even name single such change for iOS.

I can give you one. A few years back an important interface was arbitrarily renamed in the CoreBluetooth stack. I would look it up, but I’m on mobile and laying in bed. Ask tomorrow and I’ll find it.

anyway, I was overseeing a half-dozen BT apps for a hardware company at the time. Was a real pain to go through all those projects and #ifdef the interface name for the iOS version. Very odd change since I’ve never seen Apple do anything like that before either.

Lol this one was painful. And they also moved where the peripheral identifier is located in the object hierarchy to a superclass CBPeer which was wrapped in available MacOS 13+. So all my existing code that referenced the identifier on the CBPeripheral where it was prior to MacOS 13 needed warning suppression since identifier has been available through the object hierarchy on peripheral since forever

I support a MacOS app that connects to hardware devices via Bluetooth low energy and/or USB back to 10.7. First off, Apple makes it damn near impossible to test old versions, but we have every OS in a parallels VM and have copies. Every single release introduces breaking changes. We also bundle a version of our app on the hardware device and this is a big deal for us when an old version stops running on a new machine/OS. The way they’ve changed ATS over the years has broken across major versions.

They’ve changed Bluetooth chipsets a number of times over the years and each one has its own behaviors which makes writing one single BLE communication library that works for all versions very difficult. For instance, in the latest chipset, if you try to increase throughput by using a mixture of ble characteristic writes with and without response, you can very easily end up in a deadlock situation. It appears the hardware buffer just drops ble packets including those with response if full (which appears to hold 5 packets in the latest 2019 MacBook Pro). Dropping without response packets is fine since they’re expected to be unreliable (and you can build a reliable protocol on top) but they drop the write with response packet which the firmware blocks forever on (you can see this pretty clearly when using a ble packet logger). There’s no timeout and all subsequent packets are queued and never sent. Reliable writes should never be dropped!

Every new MacOS/iOS release is a worrying event. Testing the betas which are super unstable increases the tension because you never know if they’ll fix certain breaking changes. Up until the latest beta, our app did not work on iOS or MacOS until they rolled back some ATS hardening because they didn’t like the certificate pinning style we did of manually evaluating trust (which worked countless versions back).

> Honestly, I can’t even name single such change for iOS.

It's not horrible, but UINavigationController is quite infamous for changing internally with each release and behaving strangely with apps until you utter the right incantation to make it work right.

> Honestly, I can’t even name single such change for iOS. At worse it is adding interface implementation.

Airplay. Airplay has had several significant behavioural changes over the past five years, some of which still aren't even documented.

Airplay 2 wasn't so much a functionality release so much as throwing out a lot of technical debt.

Reply on news.ycombinator.com