Relying on Apple hardware for a product will likely fuck you over sooner or later
The company I work for feels exactly the opposite, we develop a SAAS POS solution that only runs on iPad. It's a lot easier, because we have a consistent environment, everyone runs almost the same hardware, and the same OS version, unlike Android, where everyone runs different versions of android and different hardware.
Relying on Apple may fuck us over in the future, but Android would be fucking us from the start.
100% agree with you. I helped develop an app that's like a POS system for a security-conscious community. The preference was to use android because of the low acquisition cost... but that was thrown out almost immediately because of the hoops necessary to meet the various security requirements.
With iOS/iPad, the team had a working MVP type product done in a few days (most of the heavy lifting was already done in a backend available via API). The MDM solution provided an on-demand VPN capability which took a lot of network activity out of the critical path. All infrastructure build cost very little and took about 2 weeks. We literally made a decision to go on the 1st of the month, and had it in front of the key business people on the 12th of the month.
Even if Apple fucked us, it's fine -- Android would have fucked us 3 times already.
Relying on Apple may fuck us over in the future, but Android would be fucking us from the start.
Sometimes having it tough from the start is good, especially if it forces you to build something more flexible. Not so good if you go on a crusade to fix every edge case specifically.
I'm speaking generally and definitely not "defending" Android here, as the platform does need too much edge-case-fixing which is usually overwhelming for small shops.
It depends. If you want to support a lot of devices / screens / versions / defaults / settings / mods / roms / whatever else I forgot, then, yes.
You can always target a sane subset, which makes the number of edge-cases manageable for a smaller team.
I had a WebView that I used to display PDFs in my application then I realized some versions of the internal browser didn't support opening PDFs. For those devices, I tried to create an intent (Was it called that? It has been so long), only to learn that many didn't come with a PDF viewer at all. So I created a service to render PDFs to images server side. A bug in the browser messed up the layout (pages with both orientations existed in documents and even a humble table layout couldn't make them display reliably across the devices). I started loading the images and displaying them in a native view. Then I had memory problems in some devices. Then I started lazy-loading each page. That seemed to work but users from smaller screens complained about double-tap-hold-zoom thing. And so on...
I agree that in cases where a specific hardware is necessary and you don't want to bundle the hardware with your software, the iPad is not a bad choice.
There might be some annoyances when Apple drops older pieces of hardware that would still be able to run your software but you can't offer it anymore as the minimum iOS target has been raised.
In the case of that Panic status board which is apparently not much more than a webview and having that tied to a particular piece of hardware is really unfortunate.
Comments
The company I work for feels exactly the opposite, we develop a SAAS POS solution that only runs on iPad. It's a lot easier, because we have a consistent environment, everyone runs almost the same hardware, and the same OS version, unlike Android, where everyone runs different versions of android and different hardware.
Relying on Apple may fuck us over in the future, but Android would be fucking us from the start.
100% agree with you. I helped develop an app that's like a POS system for a security-conscious community. The preference was to use android because of the low acquisition cost... but that was thrown out almost immediately because of the hoops necessary to meet the various security requirements.
With iOS/iPad, the team had a working MVP type product done in a few days (most of the heavy lifting was already done in a backend available via API). The MDM solution provided an on-demand VPN capability which took a lot of network activity out of the critical path. All infrastructure build cost very little and took about 2 weeks. We literally made a decision to go on the 1st of the month, and had it in front of the key business people on the 12th of the month.
Even if Apple fucked us, it's fine -- Android would have fucked us 3 times already.
Sometimes having it tough from the start is good, especially if it forces you to build something more flexible. Not so good if you go on a crusade to fix every edge case specifically.
I'm speaking generally and definitely not "defending" Android here, as the platform does need too much edge-case-fixing which is usually overwhelming for small shops.
Do you mean that by simply choosing Android as a platform, you're automatically incurring a ton of technical debt?
It depends. If you want to support a lot of devices / screens / versions / defaults / settings / mods / roms / whatever else I forgot, then, yes.
You can always target a sane subset, which makes the number of edge-cases manageable for a smaller team.
I had a WebView that I used to display PDFs in my application then I realized some versions of the internal browser didn't support opening PDFs. For those devices, I tried to create an intent (Was it called that? It has been so long), only to learn that many didn't come with a PDF viewer at all. So I created a service to render PDFs to images server side. A bug in the browser messed up the layout (pages with both orientations existed in documents and even a humble table layout couldn't make them display reliably across the devices). I started loading the images and displaying them in a native view. Then I had memory problems in some devices. Then I started lazy-loading each page. That seemed to work but users from smaller screens complained about double-tap-hold-zoom thing. And so on...
Thanks for the detailed answer. Went through a similar thing myself with a "hybrid" app. Nightmare.
I agree that in cases where a specific hardware is necessary and you don't want to bundle the hardware with your software, the iPad is not a bad choice.
There might be some annoyances when Apple drops older pieces of hardware that would still be able to run your software but you can't offer it anymore as the minimum iOS target has been raised.
In the case of that Panic status board which is apparently not much more than a webview and having that tied to a particular piece of hardware is really unfortunate.
Specifying Raspberry Pi 3 with Raspbian shouldn't be so difficult, and those things are much cheaper to deploy than an iPad.