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.
> 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.
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.
I just submitted a bug to Apple because of an api that crashes the simulator unless you target the latest version of iOS. On device you can target any previous version of iOS easily.
This is just one annoyance of many I encounter on regular basis.
They do go to great extend to allow you to support older versions, but they don’t make it always easy.
Last versions of iOS have been specially rough because SwiftUI has been constantly evolving, and keeping backward support is just a nightmare.
I disagree. Developers are VERY strongly encouraged by Apple to move their minimum deployment versions up.
New APIs and frameworks are never backported (Swift Concurrency and the COVID tracking API were notable exceptions), and additionally if you dipped your feet into SwiftUI, you've essentially jumped into river rapids. Despite its age at this point, SwiftUI is still very immature, and all the new stuff to fix its holes requires you to jump up versions or fall back to UIKit.
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.
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?
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..
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).
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.
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.
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.
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 :(
> 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.
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.
The author mentions code signing as a tricky ecosystem thing. Well, wait until the app has to get new assets to be resubmitted with bug fixes for new versions of iOS.
And if they don’t keep updating it, it will stop working and the buy it for life idea commits the dev to maintenance that isn’t paid for either upfront or through subscription.
There are folks who make and give away a lot but some learn their lesson quickly and find ways to get people to put a reasonable amount of recurring payment into the app to make it even remotely sustainable beyond a hobby.
FWIW, AI may make this cost so much lower that this kind of thing can make sense now. Something to consider, I suppose.
I think a lot of what Apple has added to their App Store in the name of security is really just to get developers to move to recurring revenue models, which in turns makes Apple a lot more money. An old app that hasn't been updated in a couple years isn't inherently dangerous, but if Apple can convince users that it is, then devs will have to rethink how they do business. It's a shame to watch Google copy this move too on the Play Store.
eg Apple publishes a new ios rev; debugging on it requires upgrading xcode; and that requires updating your OS.. Good thing you don't mind wasting a full day or more reinstalling every other devtool you may happen to use. Or xcode just doesn't connect to your ios device because reasons. (The reason is apple writes shoddy slapdash software because monopoly.)
So now you're spending another $1500+ on a studio so you can do all this in VMs and see how bad the damage will be to avoid blowing up your main devbox. etc etc.
I had an idea years ago for an app but came to the same conclusion after some market research and a risk assessment so didn’t bother. I do not regret that decision for a moment.
I either have to put enough time into the idea to do it full time or do a shitty job. I can’t win either way without incurring massive risks so I will continue to part time two jobs and invest the earnings from those wisely instead.
It’s not just that. Companies who are anywhere between unethical and outright complete scams have discovered how incredibly easy it is to get people to sign up for a free trial for something that milks them of tons of money they don’t realize.
Despite the fact that Apple tells you when your subscription will renew it doesn’t seem to help enough people. So they buy a scientific calculator app because they don’t realize that it’s built into the one on the phone and then end up paying five dollars a week for it. And even if they find out after the first renewal that means the app developer got five dollars (minus fees).
There’s tons of subscriptions out there that are just completely out of whack with their prices. And Apple just doesn’t seem to care.
At 3 days to develop, the author could make 100 of these apps a year. Of course, they will probably spend additional time developing and fixing bugs, IF the app gets any traction. And if it becomes something more substantial, they could up the price or release a preium in app purchase to upgrade with new features.
true to that. App Store is flooded with junk. it is hard to get to users even with legit free good app. and marketing is unbelievably expensive. users trust into random apps on App Store is very low too. getting iOS apps to work is very very hard.
it should go without saying that development cost, and rest of operational cost (design, legal, etc.) should be considered as zero. meaning do yourself with no pay. with all money goes into marketing. only then there is slight hope to break even.
Yes, making money on iOS is an uphill climb, many times more so if you’re not playing the TikTok ads and subscription model.
I’ve been making iOS software independently for almost 2 years now (https://heliographe.studio) and am about ramen profitable.
A few notes in case OP (or anyone interested in making some money in the App Store) is reading:
- you have to make the app free to download, and quickly demonstrate value then show a paywall if you want any purchases. Paid upfront just does not work unless you’re an already recognized product.
I had some apps that were paid upfront, and would mostly get $0 days. Switching to free to download immediately brought me to a slow but steady trickle of daily downloads, and from there you just have to work on your conversion rate.
- but that's still going to be pretty low, if you want any meaningful user acquisition, you're going to have to go look for the kind of people who might be interested in your product. The broader your potential audience is, the harder that's going to be (but that's why TikTok ads can work so well). In my case, choosing to focus on a somewhat niche area (tools for photography) is helpful; there's a strong photography community going on Threads and regularly posting on there yields good results (for now...)
- $2.99 is dramatically underselling yourself, especially if you offer a quality product that you put time to craft to your standards and has no tracking, no subscription, no ads, etc. You should play with pricing to see what the sweet spot in terms of conversion is, but in my experience it's always worth it to start at least at $4.99/$7.99 for these sort of utility apps. Of course, the design of your funnel/paywall will make a huge difference (ie you'll likely sell more of an app marked as $4.99 at 50% off, than just $4.99)
- learn about what makes for good App Store screenshots, descriptions, how keywords work, etc. Ariel from App Figures has some good videos on YouTube about what they see and what seems to work based on their data.
The days where you could make a little app, chuck it on the App Store for $.99, and have it just blow up are well over. If you want to make any money on the App Store (even if to just pay back for your Apple Developer membership), you have to put as much effort, if not more, in the marketing and promotion of your product than you put in the design & development of it. It's a grind for sure — and don't count on Apple to help you in any way (by and large they seemed more interested to promote games and dating apps with $49.99/mo subscriptions than small indies doing interesting things).
People are right it isn’t anywhere near a salary, but I have fun and it has opened job opportunities too
For marketing, I found /r/Apple very receptive to self promotion posts - just make sure you meet the criteria. You can also do a discount period and advertise on /r/AppHookup. Last Black Friday I reduced a $2 to 29c (lowest allowed price) and made just shy of $500, and it boosted my place in the store search
Code signing has been a non issue for years now. It was a complete horror show when we started 15 years ago but in today's Xcode it all just works out of the box.
Oh while a single simple setup is easier, it's still a horror show as soon as you need entitlements, more build environments, more devices (wtf does Apple makes us wait 72 hours to add one?!), ... Apple caters to kids starting development these days, not enterprise developers.
Even getting in the program takes time. I signed up on Thursday, had to send a ton of documents, and for organizations, you need a DUNS number. Whole process kind of sucks currently.
Yours looks sleeker though. One thing I learned quickly after having friends use it..other people want different things and catering to more than just myself takes soooo much time.
So I stick to building what I want and releasing it for free.
The author hasn’t yet realized that will need to re-download their app to the phone once a week even if they don’t make any changes, which is the main reason I just don’t bother with iOS development.
Not being able to easily maintain apps on hardware I own and having to check in with Apple every few days is insane, and the workarounds are ridiculous and unwieldy. It’s the principle of the thing that gets to me.
Yes I don’t mind the App Store fee but the fact I can’t write my own apps for my own phone is insanity. I’d write little apps for myself otherwise. Apple do not care about such things of course. There is no modern HyperCard
With the recent Expo SDK 53 update that introduced a slew of breaking changes, I've been contemplating switching my app to native. I could perhaps vibe code features on both android and iOS and ship features as fast as crossplatform react native devs.
I doubt it. I maintain both RN apps and other ones with both iOS and android versions and if you are not a company and your app does anything more than a todo list your iteration velocity grinds to an absolute halt. RN is just faster and that matters
Could you share which issues you had with the upgrade to 53? I just recently migrated my employer’s app to sdk 52. We are still on legacy arch for now. I’d love to know more about what I’m in for when it comes to upgrading to 53.
Readit News
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.
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.
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/
This is just one annoyance of many I encounter on regular basis.
They do go to great extend to allow you to support older versions, but they don’t make it always easy.
Last versions of iOS have been specially rough because SwiftUI has been constantly evolving, and keeping backward support is just a nightmare.
I disagree. Developers are VERY strongly encouraged by Apple to move their minimum deployment versions up.
New APIs and frameworks are never backported (Swift Concurrency and the COVID tracking API were notable exceptions), and additionally if you dipped your feet into SwiftUI, you've essentially jumped into river rapids. Despite its age at this point, SwiftUI is still very immature, and all the new stuff to fix its holes requires you to jump up versions or fall back to UIKit.
> 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.
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?
Of course there is, just take a look at any computer/laptop.
- 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..
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).
Building for older models is possible using a collection of virtual machines, or even a multi-boot old laptop.
b) All of your users are still going come through the Apple one.
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.
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 :(
Added missing context.
Dead Comment
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.
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.
Making reasonable money on iOS is hard, like, really hard, and just having a good product is definitely not enough.
Sorry to sound so pessimistic; I just want to emphasise that monetisation and marketing is at least as important on iOS as product development.
And if they don’t keep updating it, it will stop working and the buy it for life idea commits the dev to maintenance that isn’t paid for either upfront or through subscription.
There are folks who make and give away a lot but some learn their lesson quickly and find ways to get people to put a reasonable amount of recurring payment into the app to make it even remotely sustainable beyond a hobby.
FWIW, AI may make this cost so much lower that this kind of thing can make sense now. Something to consider, I suppose.
eg Apple publishes a new ios rev; debugging on it requires upgrading xcode; and that requires updating your OS.. Good thing you don't mind wasting a full day or more reinstalling every other devtool you may happen to use. Or xcode just doesn't connect to your ios device because reasons. (The reason is apple writes shoddy slapdash software because monopoly.)
So now you're spending another $1500+ on a studio so you can do all this in VMs and see how bad the damage will be to avoid blowing up your main devbox. etc etc.
Well, it's a calling card that I can flaunt whenever needed. So far, it's helped me land two jobs, and I can confidently leverage it in future too.
I never bothered with rankings or marketing, since I can send out the link to anyone.
So, that's how I get value out of the App Store.
It’s also difficult to be a solo dev on Android, Linux, macOS, Windows, the web, etc…
The safest way is to work as a developer for a company that will pay you to do it.
I either have to put enough time into the idea to do it full time or do a shitty job. I can’t win either way without incurring massive risks so I will continue to part time two jobs and invest the earnings from those wisely instead.
Despite the fact that Apple tells you when your subscription will renew it doesn’t seem to help enough people. So they buy a scientific calculator app because they don’t realize that it’s built into the one on the phone and then end up paying five dollars a week for it. And even if they find out after the first renewal that means the app developer got five dollars (minus fees).
There’s tons of subscriptions out there that are just completely out of whack with their prices. And Apple just doesn’t seem to care.
Certainly not bad for three days work.
Deleted Comment
I’ve been making iOS software independently for almost 2 years now (https://heliographe.studio) and am about ramen profitable.
A few notes in case OP (or anyone interested in making some money in the App Store) is reading:
- you have to make the app free to download, and quickly demonstrate value then show a paywall if you want any purchases. Paid upfront just does not work unless you’re an already recognized product.
I had some apps that were paid upfront, and would mostly get $0 days. Switching to free to download immediately brought me to a slow but steady trickle of daily downloads, and from there you just have to work on your conversion rate.
- but that's still going to be pretty low, if you want any meaningful user acquisition, you're going to have to go look for the kind of people who might be interested in your product. The broader your potential audience is, the harder that's going to be (but that's why TikTok ads can work so well). In my case, choosing to focus on a somewhat niche area (tools for photography) is helpful; there's a strong photography community going on Threads and regularly posting on there yields good results (for now...)
- $2.99 is dramatically underselling yourself, especially if you offer a quality product that you put time to craft to your standards and has no tracking, no subscription, no ads, etc. You should play with pricing to see what the sweet spot in terms of conversion is, but in my experience it's always worth it to start at least at $4.99/$7.99 for these sort of utility apps. Of course, the design of your funnel/paywall will make a huge difference (ie you'll likely sell more of an app marked as $4.99 at 50% off, than just $4.99)
- learn about what makes for good App Store screenshots, descriptions, how keywords work, etc. Ariel from App Figures has some good videos on YouTube about what they see and what seems to work based on their data.
The days where you could make a little app, chuck it on the App Store for $.99, and have it just blow up are well over. If you want to make any money on the App Store (even if to just pay back for your Apple Developer membership), you have to put as much effort, if not more, in the marketing and promotion of your product than you put in the design & development of it. It's a grind for sure — and don't count on Apple to help you in any way (by and large they seemed more interested to promote games and dating apps with $49.99/mo subscriptions than small indies doing interesting things).
Good luck! Eager to try your app :)
It’s not immediately clear to the layman, what value your app provides. Even to me, it got me asking what your app provides over Adobe Lightroom.
People are right it isn’t anywhere near a salary, but I have fun and it has opened job opportunities too
For marketing, I found /r/Apple very receptive to self promotion posts - just make sure you meet the criteria. You can also do a discount period and advertise on /r/AppHookup. Last Black Friday I reduced a $2 to 29c (lowest allowed price) and made just shy of $500, and it boosted my place in the store search
Best of luck!
Then you aren't even half done. You still have to undergo the memorable experience of code sign and app store review.
First wrote iOS apps in 2010. Loathed it then, loathed it now.
I shun these devices for which I can't write my own software without permission.
https://apps.apple.com/nl/app/xyz-photo/id6602894199
Yours looks sleeker though. One thing I learned quickly after having friends use it..other people want different things and catering to more than just myself takes soooo much time.
So I stick to building what I want and releasing it for free.
Not being able to easily maintain apps on hardware I own and having to check in with Apple every few days is insane, and the workarounds are ridiculous and unwieldy. It’s the principle of the thing that gets to me.
Select some photos and then select merge. The pop up that follows will let you merge only the exact duplicates.
So you can first merge all your exact duplicates, and then when that is done manually review the visually similar matches.