We have many more issues supporting multiple versions of iOS than supporting multiple versions of Android. But neither are not even close to the nightmare that was J2ME.

Another one that wasn't blessed with OEM deviations from AOSP.

We have "been blessed" with OEM deviations from AOSP (we have a big number of clients and most of them are using Android because of regional characteristics), but still we have way more issues with customers using out-dated iOS versions than users on those devices. For comparison, we have way more iOS issues than Android ones, even if Android is the vast majority of our user base (~70% of our customers).

Anyway, even including those cases it is still very far from J2ME days.

- Bluetooth issues

- Camera is hit and miss, even after the renewed API

- Apps randomly killed on the background

- Intents that don't launch as expected

- NDK debugging that cannot attach to the server running on the device

- Unstable GPGPU drivers

- Keyboard handling

- Perfectly working code that needs to be rewritten just because

Yeah so much better than J2ME.

You know, even if you're right we still see much more issues in iOS. For example, a simple Xcode minor upgrade can randomly break some flows.

> - Perfectly working code that needs to be rewritten just because

This issue is much more frequently on iOS than Android, since iOS deprecates features much faster and there is no compatibility layer between versions.

Except on Android that happens on the same Android version across devices.

> - Bluetooth issues

Aren't they rewriting this thing in Rust?

> - Camera is hit and miss, even after the renewed API

Give it time. CameraX is already vastly better than what we had before.

> - Apps randomly killed on the background

Up to OEMs.

> - Intents that don't launch as expected

?

> - NDK debugging that cannot attach to the server running on the device

Welp.

> - Keyboard handling

Fixed.

> - Perfectly working code that needs to be rewritten just because

?

- Devices never see updates, other than a select few flagship models

- It does not matter if the blame is on Google or OEMs, it is still fragmented

Circular arguments are circular.

Nope, just the Google support team arguments that ignore how similar Android is to J2ME in many aspects.

One needs to support the home team after all.

So now I am promoted to "Google support team" just because I bought to the discussion some observations from my own company? But you bringing your own observations does not put you on "Apple support team"? This seems completely fair /s.

Well, my point in the end is that even with all the issues that you pointed (some are true, some we didn't hit because we don't use those features), we still see more issues on iOS even when they're a smaller portion of our user base.

Heck, even if we got the most problematic Android phones for us (Asus budget phones comes to my mind), it is still has less issues than iOS.

It's not as bad as it used to be. The "drawers full of devices", all terrible and broken in unique ways, gave me flashbacks to the Android 2.x days.

They are still quite actuall,

https://pamartinezandres.com/running-android-tests-on-cloud-...

Especially with respect to Bluetooth quirks. Every single phone has a different set of bugs in its bluetooth components, and none of those sets are remotely empty. In the end, we decided we could only afford to support the 5 most popular models of the day and if you don't have that phone, then too bad for you.

That one doesn't seem like purely on Android. I've never seen a device without Bluetooth bugs. The protocol is so complicated and implementation relies so much on chips that never get fixes that I'm surprised it works anywhere.

I wasn't criticizing Android, I was criticizing Android phones. I'm sure iPhone doesn't implement the protocol perfectly either, but we certainly observed fewer issues. Whether that's because our BT stack vendors did more testing with Apple devices or because Apple has fewer bugs or both, I'm not sure.

From my experience Apple’s Bluetooth stack is more stable than a typical Android stack and miles better than the Windows one. I have so many headphones that can pair with a Windows laptop exactly once, getting them to work again requires a full reset on both sides every time.

It was kind of bad until recently, it's ok now but gets a lot of custom protocol help if you buy AirPods.

There's a lot of tuning needed to avoid desense issues when your device supports 3+ wireless protocols - that's why your PC motherboard comes with an external antenna for Bluetooth and your iPhone doesn't.

But then they still insist on removing the headphone jacks because "wireless is better".

Don't get me started on programming with BLE on Android. *shudders*

I literally yesterday had to buy my first iphone since the 3G because my wife bought some BLE hardware for her work that won't work properly with her Pixel 3. (It's a set of 12 devices and the Pixel can only connect to six at a time). The manufacturer won't even list Android devices they claim to have tested it with.

Our management kept asking us to fix these issues with software. We tried things like transparently rebooting our BT module and prompting the user to do common fixes (e.g., "turn your phone off and on again") but most of the time these wouldn't work, unsurprisingly.

It's gotten much much better in the modern times. Android 2.x would break your app in many spectacular ways, but Google has been steadily adding more coverage to its "compliance test suite" that a device must pass to be eligible for Play Services preinstall. On 4.x, there were some Chinese phones, like Xiaomi and Meizu, that meddled with notifications, action bars and list views, sometimes to the point of making your app crash, and I do remember having to work around them. But if you support Android 6.0+, like many new apps do these days, you don't have to worry much about device compatibility.