5 ms·

Coming from embedded development, where it's mostly crappy SOC vendors providing a barely-working SDK and toolchain they cobbled together from an ancient versio

Coming from embedded development, where it's mostly crappy SOC vendors providing a barely-working SDK and toolchain they cobbled together from an ancient version of gcc, moving to iOS development / Xcode was in most aspects a breath of fresh air. It does have its annoyances, though. Code signing, provisioning profiles, entitlements, AppStore wizardry... And the developer program fee is a bummer: It means you can't sustainably release free apps unless you're willing to just ignore that you're burning $100 a year forever. Other frustrations: Apple makes it difficult to maintain support for older devices. They insist you keep updating your tools, but the updated tools tend to drop support for older SDKs and devices. You have to kind of go out of your way to keep your app targeting them. You can see how this plays out by getting a second hand iPhone 7 today and go to the AppStore looking for apps. It will be very difficult to find an app that will run on it. This phone is not that old, but the ecosystem abandons you pretty quickly. They also deprecate things like crazy, so every time you update your tools, you get more warnings about APIs Apple would rather you stop using. It's tough to just write an app once in 2016 and keep it limping along forever. They clearly favor developers who are 1. doing it for a living, 2. targeting latest and greatest devices, 3. updating their app and their tools frequently, and 4. don't mind doing surgery every year to move away from deprecated stuff.

peterburkimsher 1y ago
The solution for code signing is coming: through jailbreaks or appdb.to, it's possible to sideload apps without the official app store process. The EU even mandated that there should be other app stores. Building for older models is possible using a collection of virtual machines, or even a multi-boot old laptop.
- threeseed 1y ago
  a) You still need to code sign on alternative app stores. b) All of your users are still going come through the Apple one.
  - ensignavenger 1y ago
    Reg B... Will they? From what almost everyone I have heard from says, most of their users come thru their own marketing efforts, not Apples.
inquirerGeneral 1y ago
[dead]
jkestner 1y ago
Yeah, I hate the code rot that the push for the latest SDKs brings. I’ve kept old Xcode versions around, and don’t jump for every OS update so _those_ don’t rot. Kept an app (useful to dedicate old devices to) running on iOS 9 until last year. Probably could’ve gone longer with containers.
gyomu 1y ago
> the updated tools tend to drop support for older SDKs and devices. You have to kind of go out of your way to keep your app targeting them. You can see how this plays out by getting a second hand iPhone 7 today and go to the AppStore looking for apps. It will be very difficult to find an app that will run on it. This phone is not that old, but the ecosystem abandons you pretty quickly. Well, you're mixing 2 things here: Apple's tooling support for older versions of iOS, and what developers choose to do. Today, you can create a new app in Xcode, choose "iOS 15" as the minimum deployment version for your project, and you'll have an app that runs on devices going back to the iPhone 6S/first generation iPhone SE. Even supporting back to iOS versions prior to that is fairly straightforward (you'll just have to edit a plist by hand rather than use the UI picker if creating a new project) - I have some older iOS 9 projects that still compile without any issues (just tested for the sake of this comment). But to your issue of most apps not working on an iPhone 7 - that's because many developers will choose to only support iOS 16/17 or later (and the iPhone 7, a 9 year old device, stops at iOS 15). That's their choice though, not a failing of Apple's tooling.
- trinix912 1y ago
  Apple requires developers to build the apps with at least Xcode 16 targeting the SDK of least iOS 18 to submit new apps / updates to the App Store [1]. This limits how far back you can go with the iOS version, thus dropping older phones. Yes, you can definitely download older SDKs and target older iOS versions, but you cannot publish those apps on the App Store anymore. [1] https://developer.apple.com/news/upcoming-requirements/ https://developer.apple.com/news/upcoming-requirements/
  - gyomu 1y ago
    That phrasing is misleading. You can absolutely publish apps that target versions of iOS prior to iOS 18; eg all my apps are iOS 15+, I published one as recently as last week. You can build an app with the iOS 18 SDK that target previous versions just fine (as long as your calls to APIs posterior to the version you’re targeting, if any, are wrapped in the proper macros) and submit them to the App Store. So yes, you have to build your apps with the latest SDK to publish them - but that doesn’t restrict the target OS version in any way (ie I can build apps that target iOS 9 with the iOS 18 SDK). Where it starts to be a pain for new apps built in 2025 is if you want to target pre iOS 13, as you’ll have to use the older AppDelegate mechanism, but still totally doable. (That’s getting deprecated with the next release, but deprecated APIs still build just fine).
zeeeebo 1y ago
There's also the frustration where an Xcode can target iOS versions lower than the iPhone simulator's minimum. I was targeting iOS 12 for a while but it was a pain having to get UTM and an older version of Xcode just to debug/test it.
xnyan 1y ago
I had to respond, not because I think you are wrong, but because I have had almost exactly the opposite experience and conclusions from you apparently. > iPhone 7 I still have one as a TV device for me and my son to watch paw patrol. I can only speak for the set of apps I use on it, but as of a few hours ago they all still work (streaming, email, browser. no banking or other apps in that class). I am looking to replace it as it's no longer getting updates as of this march. >This phone is not that old Kind of very confused by this. It's 9 years old, it just stopped getting security updates three months ago. Is there anything even close to that outside of the iphone world? I do own android devices, I don't have anything android and nine years old that can turn on much less run an application.
- ryandrake 1y ago
  I think it’s weird how confused people get when you suggest a 9 year old electronic device should work. Every computer in my house is over 10 years old. My A/V receiver and home theater speakers are 15 years old. My TV is 18 years old. My electronic thermostat is 11 years old. While they no longer receive firmware updates, they all continue to work as well as they worked on the day I bought them. For some reason, nobody expects this of phones and tablets. The manufacturer cuts you off from updates and now somehow you’re obsolete! The 3rd party developer ecosystem pulls their old-device-supporting apps, and suddenly the device is useless. I don’t know why we accept this! What is so special about phones where we allow them to be considered obsolete so quickly?
  - abtinf 1y ago
    > My TV is 18 years old … they all continue to work as well as they worked on the day I bought them. This is unlikely to be true. The process is slow so you may not have noticed it, but the tv is probably much dimmer than when it was brand new. You may have a reasonable point about device longevity, but comparing full blown, internet connected, general purpose computing devices to an A/V receiver is obviously intentionally obtuse.
    - ryandrake 1y ago
deadbabe 1y ago
> It means you can't sustainably release free apps unless you're willing to just ignore that you're burning $100 a year forever. The fact that this $100 yearly fee has never been adjusted for inflation, in a time when developers are easily shelling out $200 a month to use LLMs, makes this gripe all the more petty. Especially when software developers are still among some of the highest paid jobs on the market.
- josephcsible 1y ago
  The difference is that LLMs are optional, but the Apple tax is mandatory.
- TheDong 1y ago
  Back in the days of newgrounds, a bunch of kids learned to program by picking up flash, making games, and sharing them with their friends. That would not have happened if you had to pay even $1/year to publish a .swf file. Now, their friends all have iphones, and if a kid could hack out an app for their friend group and share it around, it would give them great motivation to learn and hack in that ecosystem. It's kids, idealistic OSS hackers, and people in the global south who see the $100/year and give up. It's also just plain dumb rent-seeking that no other OS does. I can make an APK for a friend for free, I can make an exe for a friend, an elf for a friend, etc. Yet, even if I live in the EU and thus can distribute apps to my friends to sideload directly, even then I'm required to pay $100/year or my app stops working.
  - deadbabe 1y ago
    The AppStore is not the internet. There is no reason for it to be polluted with everyone’s throwaway side projects.
    - tebbers 1y ago
      Even more of an argument for free sideloading then. Ping your friends a URL, they click it and can install your app. All without the need for an App Store.
    - 1y ago
anta40 1y ago
For me, the some of biggest annoying about mobile app development is how the dev environment is space/RAM hungry: - gradle folder easily reach 7 or 8 gigs per project (more external dependencies = bigger) - Android/iOS emulator also need something like 7 GB (per device). Imagine if you have 3 emulators: Pixel 3 running Android 13, Pixel 4 running Android 14, etc etc Also agree code deprecation is something often happen. Most of my experience is Android, and yes I've seen emails from Google saying something like "if you don't need this feature, don't call API X and use Y instead. Failure to comply to this within 1 month will result your app is taken down." Oh well..
bboygravity 1y ago
I'm in embedded development right now (switched from EE, because higher pay, easier to find clients and more flexibility). Would you recommend the switch from embedded to app writing? What I'm looking for: more location independence (no on-site work) and more clients/work/jobs.
- zerr 1y ago
  What about switching from app dev to embedded? Is an EE knowledge required?
  - HeyLaughingBoy 1y ago
    Depends on how close to bare metal you are. However, the money you make will decrease substantially.
    - zerr 1y ago
      > the money you make will decrease substantially Due to oversupply of Embedded Developers?
      - HeyLaughingBoy 1y ago
        Compared to the market size, yes.
monegator 1y ago
yeah, no. I do both (and to the user asking for an opinion wether to switch from embedded to app.. don't!) and i loathe making apps. Sure, the dev tools are supposedly better, more modern.. but they are also an evermoving target. You can never declare a project done. This is because every new OS update breaks compatibility in subtle ways, or new requirements or behaviour changes remove capabilities you were using before and were essential for your app, or simply: the new major update breaks BLE / Wifi / Background operation and you waste three weeks of your life trying to make it work again, only to find that an OS update restored things. This happens every single year, at least once. Then you have the store policy (Play store for example) that changes the Target SDK so you MUST recompile the app with the new SDK or else, and the iOS certificate expiring every year so you have to pay for the privilege, then you have to recompile / resign... which means that the project must be compilable at all times, and every year the SDK version changes, the toolchain changes. In the embedded world i can effectively freeze the development environment, with my ancient GCC version, and it will work forever. Well, that's not really true anymore if you use Zephir, IDF or other framework monters :(
jhatemyjob 1y ago
$100 a year is nothing
- DrammBA 1y ago
  > $100 a year is nothing to me Added missing context.
- homebrewer 1y ago
  It's a week's salary for a typical junior developer in my neck of the woods.
  - jhatemyjob 1y ago
    Is your junior developer ChatGPT pro? It's either that, or you live in Zimbabwe
basisword 1y ago
>> Code signing, provisioning profiles, entitlements, AppStore wizardry Maybe it's because I've been doing iOS development since the original SDK, but this stuff is now super automated. I can't remember the last time I thought about any of it other than enabling some entitlements (and that's done in Xcode with a checkbox now). >> Apple makes it difficult to maintain support for older devices. I'm not sure I agree with this either. I work with a range of large iOS devs and they're all still supporting iOS 12 and 13 without much difficulty. Sure, you can't use the latest and greatest API's but there's nothing blocking you from using the API's supported by the older OS versions. Regarding the iPhone 7 - it's very old. Nearly a decade old. And even at that it still supports iOS 15 which is only a couple of years old. Generally I find indie shops will force you to use the most recent couple of OS versions because they want to use the new API's and don't want the overhead of maintaining support for older ones. Any app that's relying on having lots of users is supporting as far back as possible (particularly when it comes to iPad because those users keep their devices far longer).

peterburkimsher 1y ago

The solution for code signing is coming: through jailbreaks or appdb.to, it's possible to sideload apps without the official app store process. The EU even mandated that there should be other app stores. Building for older models is possible using a collection of virtual machines, or even a multi-boot old laptop.

threeseed 1y ago
a) You still need to code sign on alternative app stores. b) All of your users are still going come through the Apple one.
- ensignavenger 1y ago
  Reg B... Will they? From what almost everyone I have heard from says, most of their users come thru their own marketing efforts, not Apples.

inquirerGeneral 1y ago

[dead]

jkestner 1y ago

Yeah, I hate the code rot that the push for the latest SDKs brings. I’ve kept old Xcode versions around, and don’t jump for every OS update so _those_ don’t rot. Kept an app (useful to dedicate old devices to) running on iOS 9 until last year. Probably could’ve gone longer with containers.

gyomu 1y ago

> the updated tools tend to drop support for older SDKs and devices. You have to kind of go out of your way to keep your app targeting them. You can see how this plays out by getting a second hand iPhone 7 today and go to the AppStore looking for apps. It will be very difficult to find an app that will run on it. This phone is not that old, but the ecosystem abandons you pretty quickly. Well, you're mixing 2 things here: Apple's tooling support for older versions of iOS, and what developers choose to do. Today, you can create a new app in Xcode, choose "iOS 15" as the minimum deployment version for your project, and you'll have an app that runs on devices going back to the iPhone 6S/first generation iPhone SE. Even supporting back to iOS versions prior to that is fairly straightforward (you'll just have to edit a plist by hand rather than use the UI picker if creating a new project) - I have some older iOS 9 projects that still compile without any issues (just tested for the sake of this comment). But to your issue of most apps not working on an iPhone 7 - that's because many developers will choose to only support iOS 16/17 or later (and the iPhone 7, a 9 year old device, stops at iOS 15). That's their choice though, not a failing of Apple's tooling.

trinix912 1y ago
Apple requires developers to build the apps with at least Xcode 16 targeting the SDK of least iOS 18 to submit new apps / updates to the App Store [1]. This limits how far back you can go with the iOS version, thus dropping older phones. Yes, you can definitely download older SDKs and target older iOS versions, but you cannot publish those apps on the App Store anymore. [1] https://developer.apple.com/news/upcoming-requirements/ https://developer.apple.com/news/upcoming-requirements/
- gyomu 1y ago
  That phrasing is misleading. You can absolutely publish apps that target versions of iOS prior to iOS 18; eg all my apps are iOS 15+, I published one as recently as last week. You can build an app with the iOS 18 SDK that target previous versions just fine (as long as your calls to APIs posterior to the version you’re targeting, if any, are wrapped in the proper macros) and submit them to the App Store. So yes, you have to build your apps with the latest SDK to publish them - but that doesn’t restrict the target OS version in any way (ie I can build apps that target iOS 9 with the iOS 18 SDK). Where it starts to be a pain for new apps built in 2025 is if you want to target pre iOS 13, as you’ll have to use the older AppDelegate mechanism, but still totally doable. (That’s getting deprecated with the next release, but deprecated APIs still build just fine).

zeeeebo 1y ago

There's also the frustration where an Xcode can target iOS versions lower than the iPhone simulator's minimum. I was targeting iOS 12 for a while but it was a pain having to get UTM and an older version of Xcode just to debug/test it.

xnyan 1y ago

I had to respond, not because I think you are wrong, but because I have had almost exactly the opposite experience and conclusions from you apparently. > iPhone 7 I still have one as a TV device for me and my son to watch paw patrol. I can only speak for the set of apps I use on it, but as of a few hours ago they all still work (streaming, email, browser. no banking or other apps in that class). I am looking to replace it as it's no longer getting updates as of this march. >This phone is not that old Kind of very confused by this. It's 9 years old, it just stopped getting security updates three months ago. Is there anything even close to that outside of the iphone world? I do own android devices, I don't have anything android and nine years old that can turn on much less run an application.

ryandrake 1y ago
I think it’s weird how confused people get when you suggest a 9 year old electronic device should work. Every computer in my house is over 10 years old. My A/V receiver and home theater speakers are 15 years old. My TV is 18 years old. My electronic thermostat is 11 years old. While they no longer receive firmware updates, they all continue to work as well as they worked on the day I bought them. For some reason, nobody expects this of phones and tablets. The manufacturer cuts you off from updates and now somehow you’re obsolete! The 3rd party developer ecosystem pulls their old-device-supporting apps, and suddenly the device is useless. I don’t know why we accept this! What is so special about phones where we allow them to be considered obsolete so quickly?
- abtinf 1y ago
  > My TV is 18 years old … they all continue to work as well as they worked on the day I bought them. This is unlikely to be true. The process is slow so you may not have noticed it, but the tv is probably much dimmer than when it was brand new. You may have a reasonable point about device longevity, but comparing full blown, internet connected, general purpose computing devices to an A/V receiver is obviously intentionally obtuse.
  - ryandrake 1y ago

deadbabe 1y ago

> It means you can't sustainably release free apps unless you're willing to just ignore that you're burning $100 a year forever. The fact that this $100 yearly fee has never been adjusted for inflation, in a time when developers are easily shelling out $200 a month to use LLMs, makes this gripe all the more petty. Especially when software developers are still among some of the highest paid jobs on the market.

josephcsible 1y ago
The difference is that LLMs are optional, but the Apple tax is mandatory.
TheDong 1y ago
Back in the days of newgrounds, a bunch of kids learned to program by picking up flash, making games, and sharing them with their friends. That would not have happened if you had to pay even $1/year to publish a .swf file. Now, their friends all have iphones, and if a kid could hack out an app for their friend group and share it around, it would give them great motivation to learn and hack in that ecosystem. It's kids, idealistic OSS hackers, and people in the global south who see the $100/year and give up. It's also just plain dumb rent-seeking that no other OS does. I can make an APK for a friend for free, I can make an exe for a friend, an elf for a friend, etc. Yet, even if I live in the EU and thus can distribute apps to my friends to sideload directly, even then I'm required to pay $100/year or my app stops working.
- deadbabe 1y ago
  The AppStore is not the internet. There is no reason for it to be polluted with everyone’s throwaway side projects.
  - tebbers 1y ago
    Even more of an argument for free sideloading then. Ping your friends a URL, they click it and can install your app. All without the need for an App Store.
  - 1y ago

anta40 1y ago

For me, the some of biggest annoying about mobile app development is how the dev environment is space/RAM hungry: - gradle folder easily reach 7 or 8 gigs per project (more external dependencies = bigger) - Android/iOS emulator also need something like 7 GB (per device). Imagine if you have 3 emulators: Pixel 3 running Android 13, Pixel 4 running Android 14, etc etc Also agree code deprecation is something often happen. Most of my experience is Android, and yes I've seen emails from Google saying something like "if you don't need this feature, don't call API X and use Y instead. Failure to comply to this within 1 month will result your app is taken down." Oh well..

bboygravity 1y ago

I'm in embedded development right now (switched from EE, because higher pay, easier to find clients and more flexibility). Would you recommend the switch from embedded to app writing? What I'm looking for: more location independence (no on-site work) and more clients/work/jobs.

zerr 1y ago
What about switching from app dev to embedded? Is an EE knowledge required?
- HeyLaughingBoy 1y ago
  Depends on how close to bare metal you are. However, the money you make will decrease substantially.
  - zerr 1y ago
    > the money you make will decrease substantially Due to oversupply of Embedded Developers?
    - HeyLaughingBoy 1y ago
      Compared to the market size, yes.

monegator 1y ago

yeah, no. I do both (and to the user asking for an opinion wether to switch from embedded to app.. don't!) and i loathe making apps. Sure, the dev tools are supposedly better, more modern.. but they are also an evermoving target. You can never declare a project done. This is because every new OS update breaks compatibility in subtle ways, or new requirements or behaviour changes remove capabilities you were using before and were essential for your app, or simply: the new major update breaks BLE / Wifi / Background operation and you waste three weeks of your life trying to make it work again, only to find that an OS update restored things. This happens every single year, at least once. Then you have the store policy (Play store for example) that changes the Target SDK so you MUST recompile the app with the new SDK or else, and the iOS certificate expiring every year so you have to pay for the privilege, then you have to recompile / resign... which means that the project must be compilable at all times, and every year the SDK version changes, the toolchain changes. In the embedded world i can effectively freeze the development environment, with my ancient GCC version, and it will work forever. Well, that's not really true anymore if you use Zephir, IDF or other framework monters :(

jhatemyjob 1y ago

$100 a year is nothing

DrammBA 1y ago
> $100 a year is nothing to me Added missing context.
homebrewer 1y ago
It's a week's salary for a typical junior developer in my neck of the woods.
- jhatemyjob 1y ago
  Is your junior developer ChatGPT pro? It's either that, or you live in Zimbabwe

basisword 1y ago

>> Code signing, provisioning profiles, entitlements, AppStore wizardry Maybe it's because I've been doing iOS development since the original SDK, but this stuff is now super automated. I can't remember the last time I thought about any of it other than enabling some entitlements (and that's done in Xcode with a checkbox now). >> Apple makes it difficult to maintain support for older devices. I'm not sure I agree with this either. I work with a range of large iOS devs and they're all still supporting iOS 12 and 13 without much difficulty. Sure, you can't use the latest and greatest API's but there's nothing blocking you from using the API's supported by the older OS versions. Regarding the iPhone 7 - it's very old. Nearly a decade old. And even at that it still supports iOS 15 which is only a couple of years old. Generally I find indie shops will force you to use the most recent couple of OS versions because they want to use the new API's and don't want the overhead of maintaining support for older ones. Any app that's relying on having lots of users is supporting as far back as possible (particularly when it comes to iPad because those users keep their devices far longer).