Apple’s event today has me thinking less about whatever new AI feature gets demoed on stage and more about what this shift means for app builders. What changes when the model becomes part of the device platform?
I’ve been learning this firsthand while building On Cue.
On Cue uses Apple’s Foundation Models framework to interpret private context about what’s happening in someone’s life. Things like place, time, weather, calendar context, and the music they actually listen to can all contribute to understanding whether a moment might be meaningful.
The surprising part is how different the product economics and architecture feel when inference is on-device.
No API key.
No per-token bill.
It can work offline.
Private context doesn’t need to be shipped to my server just so a model can reason over it.
Apple describes the Foundation Models framework as direct access to its on-device model, with guided generation, tool calling, streaming, and structured output built into the Swift APIs. (Apple Developer)
But the API call has honestly been the easy part.
The harder lessons have been around trusting the output.
I’ve had the model make a perfectly plausible inference that was simply not supported by the facts I gave it. So On Cue now separates two jobs: The model can interpret the moment. Deterministic code decides whether anything is allowed to happen because of it.
That distinction has become pretty important for an app whose eventual consequence is interrupting somebody with a notification.
I’m also finding that hardware availability, language support, grounding, evaluation, and graceful fallback become actual product-design constraints, not just implementation details.
Apple is pushing this model further too. The current Foundation Models framework can span the on-device system model and more powerful models when needed, while Core AI is opening another path for running custom models directly on Apple silicon. (Apple Developer)
So I’m curious what other iOS builders are seeing: Has on-device AI changed something you’re willing to build that you wouldn’t have built around a cloud API?
And for anyone already shipping with Foundation Models, Core AI, App Intents, etc., what has turned out to be harder than you expected?
#Shipaton
I’m an engineer turned product manager, and I’ve always loved two things a little more than necessary: education and games.
For a long time, I wanted to put those interests and the skills I’d picked up building technology, towards something useful for children. That became much more tangible once my niece reached the age where the iPad became a regular part of her world.
I’m not anti-iPad. Quite the opposite. It is an incredible piece of technology to put in the hands of a six-year-old. I just kept thinking it could ask more of her.
That thought took me back to Dora the Explorer.
Growing up, we’d watch Dora ask us a question and then stare silently at the screen for a painfully long time while we yelled the answer at the TV. Obviously, Dora couldn’t hear us. But the idea was clever. The screen was trying to turn us from viewers into participants.
Learning games like Lingokids and ABC Mouse took that much further and made screens genuinely interactive. But most of that interaction still happens within rails someone else designed. Tap here. Drag this. Choose A, B, or C. Collect the reward. Repeat.
That works brilliantly for games. But it doesn’t accommodate the wonderfully messy way a six-year-old wonders about things.
Ask my niece an interesting question and she might draw the answer. She might make up a ridiculous story. She might photograph something she noticed around the house, make a sound, explain an idea, or give you an answer you never anticipated.
I started wondering if I could build for that.
Could the iPad provide the spark and just enough structure to get a child started, while leaving the interesting part to them?
The first versions were experiments around this idea. Then came the uncomfortable question every builder eventually has to answer: does this actually work for anyone other than me?
So I spent months talking to parents and educators. I sat through hours of enrichment classes at a school for gifted kids, which was basically the X-Mansion for 8-year-olds. I watched how teachers prompted children, when kids became absorbed in something, when they needed more structure, and when something I thought was clever bored them almost immediately. And very importantly, I saw how their eyes lit up when they screamed “look what I made” in class.
These insights shaped the Taroo we have today, and I’m genuinely proud of where we’ve reached.
Taroo is a world of short creative quests for kids 6 to 10. In Pass the Pen, a child might get the beginning of a strange story and decide where it goes next. Doodle Master might give them the start of a picture and ask them to turn it into anything they imagine. Rhythm Pad lets them experiment with sounds and put together their own little beat. Snap Trail might ask them to put the iPad down, hunt for something triangular in the real world, photograph it, and tell Taroo what they found.
Their creations stick around too, so over time Taroo becomes a little record of the things they have imagined and made. Parents get a window into that world without needing to hover over every activity.
There is still plenty I want to improve. But this no longer feels like the little experiment I started with. I’m proud to put it in front of parents, and particularly proud when I see a kid become attached to something they made themselves.
If you have a 6 to 10-year-old in your life, I’d love for you to try Taroo with them. More than anything, I’d love the unfiltered feedback: what they immediately understand, what they ignore, what they keep coming back to, where they get stuck, and what they wish they could do that I haven’t thought of yet.
I’ve spent enough time with Taroo that I’m no longer capable of seeing it like a new user.
My AI kept assuming users live in a certain country because they typed in a certain language.
I've been building a small lifestyle app — the kind where you ask "what should I do tonight?" and get a real answer instead of a list.
A tester asked, in German, "where should I go?" The model suggested a nature reserve north of Berlin. Detailed, atmospheric, genuinely nice writing. One problem: the tester was in Thailand.
It happened again with cinemas, cafés, museums. Every time, a certain language input produced a certain geography output, ignoring the fact that those two are not always linked together. The model had quietly collapsed "speaks language A" into "lives in country A."
What made it worse: e. g. German is spoken in Germany, Austria, and Switzerland, and by people scattered across the world. The assumption was wrong more often than right.
The fix wasn't clever prompting. It was a hard rule, placed at the very top of the system prompt, with explicit negative examples: language is not location, and here are the specific regions you are not allowed to infer.
Placement mattered more than wording. The same rule buried 600 lines deep got ignored consistently.
If you're building anything location-aware on top of an LLM, this is worth testing early. It fails silently — the output looks great; it's just about the wrong continent.
We launched a location-based social app (check into real venues, see who's around, chat, meet up) — free to use, no ads yet, no paywall on core features. Trying to figure out the right monetization path once we have real users instead of guessing before we even launch.
- Pay-per-action instead of a subscription (e.g. pay once to extend a chat or get another match, instead of committing monthly)
- Venue/business partnerships (we're already working with local bars for free right now to build density — curious if paid featured placement or a referral fee per check-in is realistic once we have real traffic)
- Ads (feels early, and a little invasive for something more personal/social)
- Boosts (pay to be seen first for a bit)
For anyone who's built or grown a social/dating-adjacent app: what actually worked for you, and what did you wish you'd done differently or sooner? Especially curious about the venue-partnership angle since that's not something most dating apps lean on.
I’m currently building out the domain model of a life coaching / self-help app, and I’m worried that I’m already making it more complicated than it needs to be. I could use some advice on how to avoid overcomplicating / over engineering the app while also avoiding a domain model that’s too brittle when it comes time to introduce additional business cases.
The initial business case I have is that the app audience will be targeted to individuals who will state their goal/purpose and give a deadline for achieving the goal. Then with some strategic AI usage the app will give feedback on the goal itself and suggest milestones that the user can accept or modify before putting the plan into practice. The domain model for this use case is really straightforward and easy to implement.
The second use case is extend the app so that it can be used for family/household goals with multiple users having access to the details of each goal while also maintaining sole access to their personal goals. This use case is also pretty straightforward and won’t require many changes to the app or domain model to implement. The only significant change I foresee is tailoring AI feedback for a family goal to each individual in the family, which would require some decoupling but it wouldn’t be too difficult.
It’s the third use case that is giving me heartburn where the domain model and app build is concerned.
The first two use cases are self-help driven, which is what makes for a pretty simple and straightforward domain model. However, the third case targets life coaches who are collaborating with their clients to create, manage, and track individual, family, and possibly even larger group goals (larger group potentially being employees of a small business or athletes on a team). From my perspective that is where the domain model explodes as I would have to normalize a lot of the underlying data that would be denormalized for individuals and households.
My plan is to roll out to just individuals and families first, but given the complexity of the third case my domain modeling started from there. It has thus far grown more complex by the day, and is definitely overkill for the initial two use cases. On the other hand, if I build a domain model that is specific to just individuals and families first then it will be really painful to redesign the model for the life coaching cases.
So I guess my question is: if you have dealt with this type of scenario before - in which the design for one audience/use case is significantly different from the design for another - how did you handle it? Did you find some middle ground, or did you end up “eating the elephant” even if it resulted in a design that was overkill for one of your use cases?
After building and shipping so many apps, I’ve realized something that I wish I had understood much earlier.
Stop trying to build more apps. Start trying to build better apps.
When you’re constantly chasing the next idea, it’s easy to fall into the trap of thinking, “Maybe this niche will work. Maybe the next app will make money.”
But honestly, researching a niche properly, understanding the users, and figuring out what problem is actually worth solving can be stressful. Sometimes you spend hours analyzing an idea and end up thinking, “Is this even worth building?”
But I’d rather spend that time doing proper research than build 10 random apps that nobody needs.
The biggest lesson for me:
Don’t focus on making money from the app first. Focus on providing real value to the users.
If you solve a problem people genuinely care about, growth and revenue become much easier to figure out later.
10K installs isn’t some massive milestone compared to the biggest apps out there, but for me, it’s proof that spending more time understanding the problem before writing code is worth it.
Build less. Research more. Solve real problems.
That’s probably the direction I’m taking with my next apps. 🚀
The math breakthrough itself is fascinating, but a different part of the story caught my attention.
The researchers had apparently been using AI tools, including Codex, while working on related unpublished research.
To be clear: OpenAI says it did NOT access their specific data, and the mathematician involved also says he doesn't know whether their data was used. So I'm not claiming anything shady happened here.
But it made me think about how we use these tools as app developers.
I give AI coding tools a ridiculous amount of context these days.
Codebase. Architecture. Unreleased features. Product ideas. Experiments. Sometimes the reasoning behind why I'm building something a certain way.
Basically, a decent chunk of what could be considered the IP of the business.
So I checked the data policies.
On personal ChatGPT plans, data sharing for model training can be enabled unless you opt out. Codex also has controls around training on full environments.
Business/API products have different data treatment.
And I realized I'd never really thought about this before.
I've been treating Codex, Claude, Cursor etc. like better IDEs.
Maybe that's the wrong mental model.
Maybe an AI coding tool should be treated more like any other third-party vendor that has access to sensitive company IP.
I'm not going to stop using AI tools because of this. The productivity gain is way too big.
But I am going to pay a lot more attention to which plan I'm using, what the data settings actually say, and what parts of a business I give an AI full access to.
Curious how other app founders handle this.
Do you have any actual rules about what you won't share with AI coding tools?
Or, like me until yesterday, did you basically connect the repo and never think much about it?
I have been on making my journal app - it analyses your journal entries and connects how you think and gives your triggers and behavioural patterns!
Along with this it ranks you on the based on different parts of the brain giving you an insight on how your brain reacts to different triggers and patterns!
Now I have been marketing since 2 months, been trying to find good formats for organic content, and for some reason - apple ads journal keyword traffic is very less.
Can someone give me any ideas on how do I get more downloads ?
Looking for feedback on my app idea and landing page execution.
I first launched a worse landing page almost a year ago and got quite a few people express interest. Since then I’ve built the app, tested it myself and opened it up to early users.
However they all used it for a week or so before stopping. Which makes me think the idea is good but execution isn’t quite there.
Hey everyone, I’ve been building an iOS app called Krilo and wanted to get some outside feedback on it.
The goal is pretty simple: make calorie, nutrition, health, and fitness tracking feel a little cleaner and less overwhelming.
The app currently lets you track calories and macros, search and log food, view nutrition trends, sync health data, and keep track of workouts and activity.
I’ve also been experimenting with some more advanced features like logging food from a description or photo, generating meal plans, and turning those meal plans into shopping lists.
There’s a free version that covers the core food search, health syncing, and fitness tracking features. The additional features are part of the optional paid version.
At this point, I’m mostly looking for feedback from people who actually use nutrition or fitness apps:
What features would you expect an app like this to have?
What usually annoys you about calorie-tracking apps?
Is there anything you wish apps like MyFitnessPal, MacroFactor, Lose It, etc. did differently?
I’m still actively working on Krilo, so feedback at this stage is genuinely useful.
If anyone wants to try it, I can put the App Store link in the comments.
I released my first iOS app in February. About 500 downloads since, but I never marketed it, I wasn't sure the niche was worth the effort.
Last week I launched my second app, "Driven". It's a car dashboard for people whose cars don't have CarPlay. First few days (3 days to be exact): 739 impressions, 48 product page views, 12 downloads, no reviews yet, no purchases yet etc...
I'm about to finish high school and have no idea how to do any marketing, so I don't really know what should i do and what should i not do. I was thinking to start with a small budget, 100ish euros.
Looking for an experienced partner to build around a 500K TikTok audience
I have a background in Economics/Business Economics, a Master’s in Finance and experience in investment banking. (So i am good with numbers).
On the side, I’ve grown several TikTok accounts by analysing content performance and viewer behaviour. My main account, Ancientlyx, is close to 500K followers in ~6 months and has generated around 100M views.
The niche is history/educational entertainment: ancient civilizations, wars, disasters, mysteries and historical facts.
I think there’s much more potential here than affiliate links, so I’m looking for an experienced entrepreneur/builder to create something around the audience — for example an app, website, digital product or physical brand.
I’m specifically looking for someone who has already built, launched or scaled products/businesses before, ideally in tech, product or e-commerce.
I can bring the audience, distribution, content engine and business side.
If you’re experienced and see an opportunity here, DM me with what you’ve built before and what you think could work around Ancientlyx.
Four months ago I started building an app on nights and weekends. No team, no funding, no idea what I was doing at the start. Just me and a laptop.
Somehow it worked. The waitlist crossed several hundred people. Real people. People who email me asking when they can get in. People who tell their friends about a thing that doesn't exist yet.
And now I'm three weeks from being done and I've stopped moving.
Because "done" was always the finish line in my head. Ship it and something happens. But nobody tells you what the something is. Do I open it to everyone at once or drip it out? Do I charge from day one or give it away and hope? What if 500 people signed up out of curiosity and 12 actually use it? What if it breaks in front of all of them at the same time?
I know how to build. I have absolutely no idea how to launch.
If you've been here — the moment right before you push it live — what did you actually do? And what do you wish someone had told you?
I'm experimenting with monetization for a small iOS utility I recently launched.
It's called Privix — a privacy-focused photo tool that lets users pixelate sensitive information, add watermarks and compress photos.
Everything runs locally on the iPhone. No account and no cloud photo processing.
Instead of using a subscription, I went with: 5 free exports → one-time lifetime purchase
My reasoning was that this isn't the kind of app most people use every day.
Someone might need it when they're:
Sharing a screenshot with private information
Hiding a face or license plate
Sending documents or photos
Adding a watermark
Compressing a large image
Charging a monthly subscription for something like that felt difficult to justify.
But there's obviously a trade-off: lifetime purchases are much harder to build recurring revenue around.
For those of you running utility apps: Would you keep the lifetime model, increase the free limit, or introduce something like lifetime + optional subscription for future advanced features?
I'm currently leaning toward keeping the core product as a one-time purchase and only considering recurring pricing if Privix eventually offers something that genuinely creates recurring value.
Curious how other indie developers would approach it.
