DEV Community: ios

Where the Money Is in AI Apps in 2026: A Niche Map

Kirill Lukyanov — Wed, 21 Oct 2026 11:23:25 +0000

In 2025, people spent more money in regular apps than in games for the first time. Generative AI is the main reason. But if you're thinking of building "an AI app", the money is not where it looks like it is. Chat assistants are taken. Photo, video, voice, and AI tucked inside a daily habit are where people still pay. I build iOS apps, so I pulled together the numbers by niche and wrote down where a small team can still get in.

Short version: don't build another assistant. Build something that produces a file people keep, or remove the boring step from a task people already do every day. The second one is the realistic bet for a solo developer.

This is part 1 of a short series on how people make money with AI right now. This one is about mobile apps; part 2 covers websites and web services.

The market: there is money

According to Sensor Tower's State of Mobile 2026, consumers spent $167B in apps in 2025, up 10.6%. Non-game app spending grew 21% and passed games, which grew 1.3%. Generative AI apps were downloaded 3.8B times (double the year before), and their in-app revenue nearly tripled to over $5B.

Growth hasn't stopped. Sensor Tower projects AI apps will pass $4B in H1 2026, 36% more than H2 2025. Time spent doubled year over year, from 17.2B to 36B hours. More than 200,000 apps now mention AI in their descriptions.

That last number matters most. With 200,000 apps saying "AI", the label on its own sells nothing. What sells is the job it does.

Chat assistants: the field is taken

In Q1 2026, ChatGPT, DeepSeek and Google Gemini held almost 90% of time spent in AI assistant apps (Sensor Tower). Appfigures estimates ChatGPT made $187M net on mobile in October 2025, with Grok at $8.7M, Claude at $5M and Perplexity at $3.1M. Even companies with their own frontier models are 20–40x behind.

It wasn't always like this. In 2023–2024, thin wrappers did well: Appfigures puts ChatOn at $135M and Chat & Ask AI at $109M over two years. That was before OpenAI and Google shipped good apps of their own, when people searched the App Store for "ChatGPT" and installed whatever came up first. Today the free original beats any wrapper. That's my read, not a finding from the reports.

The niche map

Figures come from different sources and aren't directly comparable: some are net of store fees, some gross, some are company claims.

Niche	Who earns	Numbers	Barrier for a small team
General-purpose assistants	ChatGPT, Claude, Grok, Perplexity	ChatGPT: $187M net in Oct 2025 (Appfigures)	Closed
Video generation & avatars	Higgsfield, HeyGen, Runway, Kling, Synthesia	Higgsfield claims $1B annualized revenue (company claim)	High: generation is expensive, margins thin
Photo: editing, retouching, product shots	Photoroom, Evoto, FaceApp, Reface, Topaz	About ten photo tools in a16z's top 50 by spend	Medium: a narrow job works
Audio: music, voice, read-aloud	Suno, ElevenLabs, Speechify, Moises	Suno is #7 in a16z's top 50	Medium
Productivity: meetings, notes, slides	Otter, Plaud, Fireflies, Gamma, Notion	15 of 50 spots in a16z's top 50	Medium: higher prices, companies pay
Companions & roleplay	Zeta, Tipsy Chat, Character.AI	$165M general + $163M romance in H1 2026, gross (Appfigures via Decrypt)	Low technically, high on moderation and reputation
Homework & study	Gauth (ByteDance), Question.AI	~$2.5M net combined in 2024 on 15M installs (Appfigures)	High: big players plus free ChatGPT
AI inside a daily habit: food, health, fitness	Cal AI and narrow trackers	Cal AI: $40M+ trailing-12-month sales, acquired by MyFitnessPal in March 2026	Low–medium: best shot for a solo dev

The a16z ranking is the top 50 consumer AI products by US consumer spend (October 2026, YipitData), web and mobile combined. More than half of the list is photo, video and audio.

Why people pay for photo, video and voice

My interpretation, but it fits the numbers.

The result is a file. You read a chatbot answer and close it. A video, an edited photo or a voiceover gets saved, posted, sent to a client. It's easier to pay for something you can take away.
Free ChatGPT is worse at it. A general assistant can draw a picture. It won't batch-remove backgrounds from forty product shots at marketplace size.
Professionals pay. Marketplace sellers, photographers, creators and marketers treat these as work tools that pay for themselves.

The flip side is cost. Every video generation costs money, and an all-you-can-eat plan will put you in the red. Credits instead of unlimited, and expensive models only on the paid tier.

Where a solo developer fits: AI inside a habit

The most telling story of the year is Cal AI. Two high schoolers built a calorie counter by photo: snap your plate, get calories and protein. In under two years it passed 15M downloads, did over $40M in sales in the trailing 12 months, and MyFitnessPal bought it in March 2026 (terms undisclosed).

The model inside isn't theirs, and food recognition isn't unique. What worked: AI removed the most tedious step of a task people already wanted to do. Counting calories was always the goal; typing in every spoonful was the problem.

The recipe:

Pick a task people do regularly, daily or weekly.
Find the most tedious step: data entry, transcription, counting.
Let AI remove that step, and keep the rest a good ordinary app.

I do this in my own fasting app: calories from a photo are part of the daily log, and recognition runs on the phone through Apple Foundation Models, offline and with no API bill. When a request costs nothing, a free tier and a long trial don't turn into losses.

A habit also fights the other AI-app problem, churn. People leave AI apps faster than regular ones, and what keeps them is the recurring task, not the model. I covered that in an earlier breakdown of RevenueCat's data.

What can break it

The platform eats your feature. If your product is one button, it'll show up in ChatGPT, Google Photos or iOS itself. Data, history and a good workflow are what protect you.
Store rules. In April 2026 Apple briefly pulled Cal AI: it took payments via Stripe outside in-app purchase and showed the weekly price more prominently than the actual charge. It came back after fixes.
Cost. A cloud model is a variable cost per user. Do the math before launch, not after the first invoice.
Companions are their own thing. Hundreds of millions in revenue, but the top 10% of apps take 89% of it (Appfigures, 2025), and moderation and reputational risk are the highest anywhere.

What I'd pick

Not an assistant, and not a video generator: the first is taken, the second needs model budgets a solo developer doesn't have. I'd take a boring recurring task in a niche where people already pay for apps (food, fitness, health, bookkeeping, photos for sellers), have AI remove the most tedious step, on-device where possible, and sell an annual plan with a long trial.

Less exciting than "my own ChatGPT". But it's what the one real success story of the year looks like.

Originally published at klukyanov.ru.

Shorter weekly write-ups (in Russian) — on Telegram.

The JustWatch app has acquired its own movie viewing platform

Hacks.gr — Wed, 21 Oct 2026 10:20:25 +0000

JustWatch has launched JustWatch TV in the US, expanding its platform into a direct streaming service with free ad-supported viewing, rentals, and a monthly ad-free subscription tier available across mobile apps, smart TVs, and web browsers.

What does the new service offer?

The service launched in the United States on Tuesday, offering access to 344 titles at launch. Among the films available for free are A Different Man, Aftersun, Captain Fantastic, Green Room, Locke, Red Rocket, Sing Sing, Stop Making Sense, Swiss Army Man, Under the Skin and We Need to Talk About Kevin.

Users can watch content without signing in to an account, but a login is required if they want to track their progress. Viewing is available through the company's mobile apps, on select TVs, and on a computer via a browser.

Subscription and rental options

Those who prefer to watch movies without ads can opt for the JustWatch TV Plus subscription, which costs $3,99 per month and includes 234 titles at launch. There’s also a lifetime subscription available for $49,99, though it’s unclear if that option will remain available permanently. The subscription also offers a 10% discount on select rentals and unlocks additional features, such as advanced search filters.

Objectives and content suggestions

The company's head of global content strategy, Quentin Carbonell, said the service aims to reach 100 million monthly users in the coming years. According to the company, data from users' searches may be used to better recommend titles across the platform's entire range of services.

Hacks.gr on Google

Set it as a preferred source for cybersecurity updates.

Preferred source

Read the original English article on Hacks.gr

Fajr is the easiest prayer to sleep through, so we turned it into a real alarm

Ahtisham Hasan Khan — Wed, 21 Oct 2026 09:03:10 +0000

Fajr, the dawn prayer, is the one most people miss. Not because they don't care. Because they're asleep.

For years prayer apps have handled it the same way: a notification at prayer time. It lights up the screen for a second, plays a short sound, and it's gone. If your phone is on Silent, you get nothing. If you're in a Sleep Focus, it waits quietly in Notification Center until you wake up, which is exactly the problem.

When Osama Fahim and I started building Nur, a free prayer app with no ads, this was the part I cared about most. I wanted the adhan for Fajr to wake you up the way your morning alarm does.

Why notifications were never going to work

iOS treats notifications as things that can wait. That's the right call for almost every app. A prayer time can't wait, but a third-party app had no honest way to say so. The workarounds were all bad: long notification sounds that get cut off, asking people to turn off Silent mode, or telling them to set their own alarm in the Clock app every night, by hand, for a time that changes every day.

Then Apple shipped AlarmKit in iOS 26. It lets an app schedule a real alarm, the same kind the Clock app makes. It rings through Silent mode and Focus, and you stop it the same way you stop any alarm. I'd already used it as a contractor on Timey, a shareable alarm app, so I knew what it could do. Fajr was the obvious place to use it next.

The tricky part: prayer times move

A morning alarm is simple. It's 7:00 every day.

Prayer times are not. Fajr shifts a little almost every day through the year, all five prayers depend on where you are, and they change when you travel. So Nur can't set one repeating alarm and walk away.

What it does instead is keep a rolling week armed. Nur works out the prayer times for the next seven days, for wherever you are, and schedules a separate alarm for every prayer you've turned on. Sunrise is skipped, since it isn't a prayer. Fajr and Maghrib are on by default and you can switch on the others.

Every time the app refreshes, it checks that week again and tops it up. You turn the alarm on once and it keeps moving with Fajr by itself.

Keeping a week of alarms in sync

Rebuilding every alarm on every refresh would be wasteful, and it can go wrong while an alarm is actually ringing. So each alarm gets an ID built from the prayer and its exact date and minute. Fajr on a given Tuesday at 4:15 always gets the same ID. When Nur refreshes, it can tell straight away which alarms already exist, which ones are still correct, and which ones changed.

Alarms that are already right are left alone. Alarms for prayers you've switched off are removed. And an alarm that is ringing right now is never touched, whatever else changes.

Things AlarmKit taught us the hard way

You can't schedule over an alarm that already exists. When someone changed their adhan recording, every alarm in the week needed the new sound. AlarmKit refused to replace them and gave back an error that didn't explain much. The fix was to cancel the old alarm first and then schedule the new one, for each prayer.

There's a limit to how many alarms an app can hold. If Nur hits it, it stops, keeps everything that was confirmed, and records how far ahead you're actually covered. That date shows in the app, so you know the alarms are set up to that day.

One failure shouldn't silence the whole week. If one prayer can't be scheduled, Nur carries on with the rest and tells you which one failed, instead of quietly giving up.

Never swap the adhan for a beep. AlarmKit plays short sounds bundled with the app, so every adhan recording is checked before it's used: it has to load and be under 30 seconds. If a recording is broken, Nur doesn't schedule a generic system tone in its place. A random beep at 4 a.m. is not what someone asked for.

Time zones will surprise you. Nur lets you follow a mosque's timetable, and someone in Karachi following a London mosque heard Isha around midnight. The app was ringing at London's moment instead of at the time shown on the screen. Now the times keep their clock reading on your phone, so the Home screen, the widgets, the Live Activity and the alarms all agree.

Staying armed when the app isn't open

A rolling week only works if the app gets to top it up. Nur asks iOS for a background refresh every few hours, but iOS decides whether that actually happens, based on how you use the app. So we don't count on it. Opening the app always refreshes the week, background refresh is a bonus, and the "covered until" date in the app tells you the truth either way.

There's also a test button in Settings that rings the adhan ten seconds later, so you can hear exactly what Fajr will sound like before you rely on it.

What I'd tell another iOS developer

If your app has a moment that really can't be missed, AlarmKit is worth a look. Treat it as a small scheduler you have to keep honest. Give alarms stable IDs, cancel before you replace, expect a limit, never fake the sound, and show people how far ahead they're covered.

And test it with Silent on. That's the whole point.

Nur is free, with no ads, on the App Store as "NUR Prayer Times, Quran, Qibla". If you try the Fajr alarm, I'd love to hear how the first morning went.

Nur is built by me and Osama Fahim.

Originally published at iahtisham.com.

I'm Ahtisham, an independent iOS developer building native Swift apps. More from me:

🌐 Portfolio and client work: iahtisham.com
💸 AppPriceKit: free App Store subscription prices by country
🧾 JustInvoice: invoice maker for iPhone
📄 ScanIt: document scanner and PDF for iPhone
🌙 NUR: prayer times, offline Qur'an and adhkar, free with no ads
🏢 PrismCode Labs

Find me on X @iAhtishamDev · GitHub · LinkedIn · Upwork

Mobile App Development Services: How to Build an App Users Love on Every Phone

Appagentix India — Wed, 21 Oct 2026 07:53:44 +0000

Your customers spend most of their screen time inside apps. If your business isn't there, or your app is slow and confusing, they'll pick someone else.

Building a good app isn't just about writing code. It takes the right plan, the right technology and a team that thinks about real users.

This guide explains how professional mobile app development services work and what to look for.

What Do Mobile App Development Services Include?
Mobile app development services cover everything needed to take an idea to the app stores and keep it running well.

A complete service usually includes:

Discovery and planning: understanding your users, goals and must-have features
UI/UX design: wireframes, screens and a simple user flow
Development: building the app and its backend
Testing: checking performance, security and usability on real devices
Launch: publishing on the Apple App Store and Google Play
Support: updates, fixes and new features after launch
Skipping any of these steps usually shows up later as bugs, poor reviews or costly rework.

Native or Cross-Platform: Which Is Right for My App?
This is one of the first decisions in any mobile app project.

Native app development means building separately for each platform: Swift for iOS and Kotlin for Android. It gives the best performance and full access to device features. It's ideal for apps with heavy graphics, complex animations or deep hardware use.

Cross-platform app development uses one codebase for both platforms. The two most popular options are:

React Native: great for teams with JavaScript skills and apps that need fast updates
Flutter: known for smooth, consistent UI and strong performance
For most business apps and startups, cross-platform saves time and cost while still giving a near-native experience. Native makes sense when performance or platform-specific features are critical.

What Makes a Mobile App Successful?
A successful app isn't the one with the most features. It's the one people open again and again.

Here's what matters most:

Speed. Users expect apps to open in seconds. Slow screens lead to uninstalls.
Simple design. Every extra tap is a reason to leave. Clean layouts and clear buttons win.
Works on real phones and networks. Many users have budget devices and patchy internet. Good apps are tested on these conditions, not just on the latest flagship.
Security. Protect user data with secure login, encrypted storage and safe APIs.
Regular updates. Fixing issues quickly and improving features keeps ratings high.

How Does the App Development Process Work?
A professional team follows a clear process so there are no surprises:

Workshop: define the problem, users and success goals
Scope: list features and decide what goes into version one
Design: create screens and test the flow with real users
Build: develop in short cycles with regular demos
Test: check every feature on multiple devices
Launch: submit to the app stores and monitor early feedback
Regular demos keep you in control. You see progress every week or two, not just at the end.

Why Should Startups Begin With an MVP?
For startups, the biggest risk isn't bad code. It's building something nobody wants.

MVP development services solve this. An MVP (Minimum Viable Product) is a simple first version with only the core features. It helps you:

Test your idea with real users quickly
Spend less before you have proof
Show traction to investors
Learn what to build next from real feedback
A good MVP focuses on one core problem and does it well. Once users respond, you can expand with confidence.

When Do You Need Custom App Development?
Off-the-shelf apps work for common needs. But many businesses have workflows that ready-made tools can't handle.

Custom app development services build software around how your business actually works. This is useful when you need to:

Connect with existing systems like CRM, ERP or inventory tools
Support field teams, bookings, deliveries or internal approvals
Own your data and avoid paying for features you don't use
A custom app grows with your business instead of forcing your team to work around its limits.

Can AI Features Be Added to a Mobile App?
Yes, and you don't need to rebuild your app to do it.

AI app solutions can add features like smart search, chat assistants, personalized recommendations and automatic data entry from photos or documents. Most of these connect through a secure backend, so they can be added to new or existing apps step by step.

The key is to start with one AI feature that solves a real user problem.

FAQs

How long does it take to build a mobile app?
It depends on features and complexity. A focused MVP takes much less time than a full-featured app with many integrations.
Should I build for iOS or Android first?
Look at where your users are. If you're unsure, cross-platform development with React Native or Flutter lets you launch on both.
Is React Native or Flutter better?
Both are excellent. React Native suits teams with JavaScript skills, while Flutter is known for consistent UI. The right choice depends on your project.
How much do mobile app development services cost?
Cost depends on features, design, platforms and integrations. Starting with an MVP keeps the first investment lower.
Can you update my existing app instead of building a new one?
Yes. Many apps can be improved, redesigned or extended with new features without starting over.
Will my app work well on budget phones?
It should, if it's built and tested for them. Testing on real low-end devices is part of a good development process.
Can AI be added to my app later?
Yes. AI features can be added after launch through APIs and a secure backend.

Conclusion
Great apps come from clear planning, the right technology and a focus on real users. Whether you need a native or cross-platform app, a quick MVP or a fully custom solution, the process matters as much as the code.

If you're planning your next app, Appagentix offers mobile app development services for iOS, Android, React Native and Flutter, from first idea to launch and beyond.

Drawing SwiftUI previews in a browser when SwiftUI only runs on Apple's systems

SwiftQuest — Wed, 21 Oct 2026 07:34:44 +0000

I've been building a SwiftUI course that runs in the browser, and the hard part was obvious from day one: Apple's SwiftUI only exists on Apple platforms, and the learner's code compiles and runs on Linux servers. Here's how it ended up working, in case it's useful to anyone or someone spots a hole in it.

A stand-in SwiftUI module

There's a stand-in SwiftUI module with the same names and signatures as Apple's. So the learner's file is the file they'd write in Xcode, import SwiftUI and all, and their mistakes get the same compiler errors.

The module draws nothing. A run turns the views into a tree of plain nodes, with each modifier wrapping what it modifies, in order. That order matters for the same reason it matters in real SwiftUI: .padding().background(.blue) and .background(.blue).padding() are different trees.

#Preview is what gets drawn

A macro can't name something a host program can find. So before compiling, the #Preview line gets rewritten to a plain let (line numbers kept, so compiler errors still point at the right line), and a generated main.swift hands every preview to the host.

One run explores the whole screen

After rendering, the host presses every control once and keeps each screen that follows, up to 160 screens within two seconds. When you tap a button in the browser, it just follows a path that was already explored, so there's no second run. A tap that crashes gets pinned to its button instead of killing the whole preview.

The browser does the layout

The browser reimplements SwiftUI's proposal and response rules: stacks sharing space by flexibility, frames and padding proposing and reporting sizes, text wrapping to what it's offered. The constants came from frames the iOS simulator printed: line heights, spacing, button padding, symbol sizes.

Checking it against the real thing

Every example is also drawn with real SwiftUI on the iOS simulator, and the two pictures are compared. The weakest spot is SF Symbols, which are stand-in icons because their licence keeps them on Apple platforms. It's close to Xcode, not identical, and you still finish real apps in Xcode on a Mac.

This is the SwiftUI part of SwiftQuest, a course I'm building. Every exercise runs on a real Swift compiler, each run in its own throwaway gVisor container (I wrote about that sandbox here). The SwiftUI course has 8 destinations and 24 quests, from your first view to one app of your own built in three milestones, and it's open to beta testers now next to the Swift course. There's no deadline, you can be approved the same day, and testers get Pro for life: https://swiftquest.dev/beta?ref=devto

Happy to go deeper on any of the above in the comments.

I measured what Safari actually gives your web page on iPhone Duo

tyoukyou23 — Wed, 21 Oct 2026 06:02:49 +0000

iPhone Duo ships on October 23. Most "is my site ready?" guides quote viewport sizes worked out from the spec sheet — screen pixels divided by three: 466 × 678 folded, 626 × 890 or 890 × 626 unfolded.

That isn't what your page gets. I opened a probe page in Safari on the iPhone Duo simulator (Xcode 27.1) and logged what the page actually receives in each pose. A few results surprised me, and two of them I haven't seen written down anywhere.

The numbers

Pose	What the page gets (`innerWidth × innerHeight`)
Folded	382 × 580	Safari puts its status bar and buttons in a column on the right. The screen is 466 wide; your page is 84 px narrower.
Unfolded, upright	669 × 825	Between Tailwind's `sm` (640) and `md` (768) — a band few sites test.
Unfolded, sideways	951 × 543	Desktop width. Still a finger. Only 543 px tall.
Folded, sideways	678 × 340	The shortest pose of all.

The inner display itself is 2853 × 2007 px = 951 × 669 pt in the simulator, so even the "626 × 890 screen" figure going around doesn't match.

Every pose reports (pointer: coarse) and no hover. Folding or unfolding fires resize; the page is not reloaded. screen.width keeps the folded value (466) after you unfold, so don't size anything from screen.

1. Wide doesn't mean mouse

At 951 px most sites switch to their desktop layout. That's where this pattern lives:

<!-- hidden on "desktop", shown on hover -->
<button class="opacity-100 sm:opacity-0 group-hover:opacity-100">Edit</button>

On an unfolded Duo — or any iPad — that button is never visible, because a finger has no hover. Gate it on the input, not the width:

@media (hover: hover) and (pointer: fine) {
  .row .edit { opacity: 0; }
  .row:hover .edit { opacity: 1; }
}

2. Half-folding is invisible to the web

I expected the half-open "tabletop" pose to show up somewhere — Viewport Segments, Device Posture, a media query. Nothing. When you half-fold the phone, Safari moves to the outer screen and the page gets exactly the folded viewport, 382 × 580. No posture event, no segments, all posture media queries false.

So on iPhone Duo there are only two states the web can see: folded and open. You don't need a tabletop layout — and you can't build one.

3. One fold fires 2–3 resizes, through a size that belongs to no pose

I logged every resize while folding and unfolding:

resize → 466 × 498     ← transient: no pose has this size
orientation → landscape
resize → 951 × 543     ← open

The 466 × 498 step happens mid-swing, while the screens are switching over. If your code re-lays out on every resize, it does that work for a frame nobody sees. Worse, a list–detail layout that docks the detail beside the list above some width will flip to a drawer and back in one gesture.

Wait for the size to settle (~150 ms of no resizes) before switching layouts. If you measure with ResizeObserver, debounce the decision, not the measurement.

4. `100vh` is taller than the page

Folded, Safari gives the page 580 px of height:


`100vh` / `100lvh`	598 — 18 px too tall
`100dvh` / `100svh`	580 — correct at rest

A full-height sheet sized with vh hides its bottom button. dvh is right — until the keyboard opens, at which point no viewport unit follows it. Read visualViewport.height for that.

5. Safari's right-hand column ignores `theme-color`

Folded, Safari's controls live in a column to the right of your page, and they don't use theme-color. Safari samples the page edge instead, and only from fixed or sticky elements. People have tried widening the page to the edge to colour it, which causes horizontal scrolling.

What worked in the simulator: an 8 px position: fixed strip on the right edge. The whole column takes its colour, and scrollWidth stays at 382 — no horizontal scroll.

.toolbar-tint { position: fixed; top: 0; right: 0; bottom: 0; width: 8px;
                background: #1e3a8a; pointer-events: none; }

Give it the colour of whatever is next to it, so it reads as part of the page.

What I'd check before Thursday

Search for width-gated hover: sm:opacity-0, md:hidden on controls, :hover rules outside (hover: hover).
Open your site at 669 px wide — between your breakpoints.
Look at your layout at 951 × 543 with touch emulation on. Is the header eating half the height?
Replace 100vh with 100dvh (keep vh as a fallback).
Delete user-agent checks — the Duo says plain iPhone.
Don't debounce resizing in general, but do let a fold settle before swapping layouts.

I packaged this up

All of the above came out of adapting a real app (a school management system our teachers use on PCs, iPads and phones), so I pulled the reusable parts into a small React library, fold-ready — zero dependencies, SSR-safe, React 17+:

import { SplitHost, Pane, useSelection, KeepPlace, ToolbarTint } from "fold-ready";

function Inbox({ mails }) {
  const [sel, setSel] = useSelection("sel");           // ?sel=42, survives reload
  const open = mails.find((m) => m.id === sel);
  return (
    <SplitHost>                                         {/* docks side by side for wide touch screens */}
      <KeepPlace>                                       {/* same row on top after a fold */}
        <MailList mails={mails} onOpen={(m) => setSel(m.id)} />
      </KeepPlace>
      {open && <Pane label="Message" onClose={() => setSel(null)}>…</Pane>}
    </SplitHost>
  );
}

useInputMode() → { touch, hover, short }, plus Tailwind variants can-hover: touch: short:
SplitHost + Pane: detail docks beside the list when there's room on a touch screen, drawer otherwise; waits for a fold to settle
KeepPlace: keeps the same item at the top (and your caret) when the width changes
ToolbarTint, useVisibleViewport, useSettledViewport
FoldReadyInspector: a dev overlay that finds hover-only controls on the current page

Mouse users keep the behaviour they had unless you opt in.

Duo Lab shows any URL in the measured poses and plays the fold step by step — including that 466 × 498 frame: https://tyoukyou23.github.io/fold-ready/#/lab

Code: https://github.com/tyoukyou23/fold-ready · npm: fold-ready

Caveat

These are simulator numbers. I'll check them on hardware when the phone arrives. If you have a Duo before I do, the demo's Measure page prints what your Safari reports and copies it as JSON — I'd love to compare: https://tyoukyou23.github.io/fold-ready/#/measure

Etisalat Recharge: Fastest Ways to Top Up Your e& Line

Telecomdesk — Wed, 21 Oct 2026 06:00:00 +0000

An e& (Etisalat) prepaid line gives you four realistic recharge routes, and they are not equally good. The difference between the best and the worst is about fifteen minutes and one avoidable queue. Here is the ranking, with the details that trip people up.

1. The My Etisalat app - the permanent fix

Card registered in the app, top-up in seconds, balance confirmation immediate. The app route also shows what the recharge bought you: credit, bonus data, or a promotional top-up bundle - information the scratch-card route never gives you. If your line tops up twice a month or more, register the card once and never think about it again. The Etisalat quick-pay page mirrors the flow on the web for anyone without the app.

2. Web quick-pay - the somebody-else's-line route

The web payment page tops up any e& number with any card. This is the route for topping up a parent's line, a domestic worker's line, or a visitor's line from your phone - no app on their device required, receipt lands with you.

3. Scratch cards and ATM codes - the cash route

Physical recharge cards are sold at every supermarket and petrol station; ATMs issue codes directly to registered accounts. Each card's scratch code is loaded by dialing the recharge sequence - the current one is documented in our Etisalat recharge guide. Watch the card's expiry date: old stock in some shops has voided codes, which the counter should replace on the spot.

4. Counters and kiosks - cash, no rush

Full-price, queue-included, but human: the right route when a dispute needs resolving in person anyway. For pure recharges it is strictly the slow option.

Two things worth knowing once

Small top-ups (the AED 10 class) sometimes carry a shorter validity window than larger ones - check what your amount buys. And promotional top-up bonuses rotate monthly; before a large top-up, glance at the app's offers screen, because the same AED 100 occasionally buys credit plus data depending on the week.

The fastest way to see every guide we maintain is the full sitemap.

5 timing bugs I hit building timed blocks with Screen Time's DeviceActivity (iOS)

ayumu kitabayashi — Wed, 21 Oct 2026 05:19:54 +0000

I build minulo, an iPhone app that hides Reels and Shorts. One feature is a timed block: lock the official Instagram app with Screen Time for, say, 30 minutes, and have it unlock on its own even if minulo isn't running. That part runs on DeviceActivity (DeviceActivityCenter.startMonitoring + a DeviceActivitySchedule, with the unlock happening in a DeviceActivityMonitor extension's intervalDidEnd).

It took five rounds of bugs to get the timing right. All five are about how the schedule's start and end are interpreted, so they apply whether you write Swift directly or go through a wrapper like react-native-device-activity (which I use, with my own additions).

1. Windows shorter than 15 minutes are rejected

Pass a 5-minute window to startMonitoring and you get an error. In my testing on device, anything under 15 minutes was refused.

My first workaround was "now + 15 minutes", which meant a 5-minute break stayed unlocked for 15. The fix was to keep the end fixed and move the start back instead:

// keep the end; pull the start back so the window is 15 minutes
export function shortWindow(untilMs: number) {
  const now = new Date();
  const e = new Date(Math.ceil(Math.max(untilMs, now.getTime() + 60000) / 60000) * 60000);
  if (e.getTime() - now.getTime() >= 15 * 60000) return { s: now, e, dated: false };
  const s = new Date(e.getTime() - 15 * 60000);
  // if the start falls on the previous day, include the date (see #3)
  return { s, e, dated: s.getDate() !== now.getDate() };
}

A start in the past is fine; intervalDidEnd still fires at the end.

2. Same hour and minute for start and end is rejected

With hour/minute-only DateComponents, a 24-hour block (13:05 today to 13:05 tomorrow) reads as start == end and is refused. I shift the start one minute later, giving a 23h59m window. Shifting it earlier would make a 1-minute window, which runs into #1.

if (s.getHours() === e.getHours() && s.getMinutes() === e.getMinutes()) {
  s = new Date(s.getTime() + 60000);
}

3. Just after midnight, hour/minute isn't enough

Because of #1, a break ending at 00:05 starts at 23:50. Sent as hour and minute only, that was read as 23:50 today, and the window broke: a 5-minute break after midnight stayed open for 15. When the start falls on the previous day, I now include year, month and day:

export function winEdge(d: Date, dated: boolean) {
  return dated
    ? { year: d.getFullYear(), month: d.getMonth() + 1, day: d.getDate(), hour: d.getHours(), minute: d.getMinutes(), second: 0 }
    : { hour: d.getHours(), minute: d.getMinutes(), second: 0 };
}

4. The number of monitored activities is limited

Registering one activity per weekday for each schedule (bedtime, class hours…) adds up fast, and the number of monitored activities is reportedly capped at around 20. Past that, startMonitoring fails, and the block simply never unlocks. Two changes:

daily schedules are a single activity without a weekday
failures are stored instead of swallowed, so the app can show that something is wrong

DA.startMonitoring(FOCUS_ACTIVITY, { intervalStart, intervalEnd, repeats: false }, [])
  .catch((x) => set('focus:nativeErr', String(x?.message ?? x).slice(0, 120)));

5. "Unblock everything" also unblocks things that should stay blocked

Clearing all shields in intervalDidEnd also removed other blocks that should still be active at that moment, like a bedtime schedule or an app whose daily limit was used up. A manual block ending in the middle of the night took the bedtime block down with it until morning.

Now the end action re-applies whatever should still be active at that time, computed when the block starts:

DA.configureActions({ activityName: FOCUS_ACTIVITY, callbackName: 'intervalDidEnd', actions: [
  { type: 'resetBlocks' },
  // re-apply schedules that are still in their window at the end time
  ...during.map((id) => ({ type: 'blockSelection', familyActivitySelectionId: id })),
] });

The extension also drops re-applies that belong to schedules already finished, so a repeating registration doesn't carry them into the next day.

Summary

Windows under 15 minutes (on device) are refused: fix the end, move the start back.
Identical start and end hour:minute are refused: move the start one minute later.
After midnight the start lands on the previous day: include the date only then.
Monitored activities are capped: merge daily schedules and record failures.
Clearing everything clears too much: re-apply what should stay, at the end time.

Related: opening your own app from a Screen Time block screen (ShieldAction can't open URLs, so I go through a notification).

minulo (hiding Reels and Shorts is free): https://minulo.app/en/?ref=devto-1021b
List of apps and methods for hiding Reels and Shorts on iPhone: https://github.com/ayumu-kitabayashi/awesome-reels-shorts-blockers

Unexpected behaviour of Expo Router deep links in production

Amit chakraborty — Wed, 21 Oct 2026 04:30:06 +0000

The situation

You are a mobile engineer on a two‑week sprint.
Your team has added a new “Invite” screen that must be reachable from an email link (myapp://invite/abc123). You follow the Expo Router tutorial, add a file app/invite/[code].tsx, run the app in the Expo Go client, tap the link on a device and the screen appears instantly.

During the nightly build, the QA team reports that the same link opened the app on Android but stayed on a blank white screen on iOS, and on Android it sometimes opened the home screen instead of the invite screen. The failure only appears in the production build generated by EAS.

Cost: the release is blocked for another day, the QA cycle is delayed, and the product manager has to explain the missing feature to stakeholders.

The rest of this guide shows why the tutorial‑level configuration breaks under production conditions, and how to make deep links reliable with Expo Router.

Why it happens

Expo Router relies on two mechanisms:

Native intent/association handling – Android intent-filter and iOS Associated Domains tell the OS that a URL scheme or universal link belongs to the app.
JS‑side route resolution – expo-router parses the incoming URL, matches it against the file‑system based route tree, and then renders the matched screen.

The tutorial usually covers only the first step for the development client:

{
  "expo": {
    "scheme": "myapp"
  }
}

In a production build the following hidden constraints appear:

Constraint	How it manifests	Why it matters
Scheme registration on Android – The generated `AndroidManifest.xml` only contains a `<data android:scheme="myapp"/>` if `expo.android.scheme` is set and the `expo-router` plugin is applied. Without the plugin the manifest lacks the `<intent-filter>` block, so Android falls back to the default activity.	Links open the app but land on the default (`Home`) screen.	The router receives `null` for `initialURL`.
Associated Domains on iOS – The iOS project must have an `entitlements` file with `applinks:myapp.com` and a matching Apple App Site Association (AASA) file on the domain. The tutorial omits this because Expo Go uses the custom scheme only.	`myapp://invite/abc123` works in development, but a universal link `https://myapp.com/invite/abc123` opened from Mail shows a white screen.	The native bridge receives the URL after the JS runtime has already rendered the home screen, causing a race where the router never processes the deep link.
Bundle‑time route hashing – Expo Router generates a route manifest (`router-manifest.json`) at build time. If a file is added after the manifest is generated (e.g., a new `[code].tsx` added in a later commit without a clean rebuild), the manifest on the device does not contain the new route.	The app logs `Unable to find route for path "/invite/abc123"` and stays on a blank screen.	The router cannot match the incoming URL.
JS runtime readiness – In production the JavaScript bundle may take 500‑800 ms to evaluate on low‑end devices. If the native side forwards the deep link before `router.isReady` resolves, the router drops the URL.	Intermittent failures on Android 6‑7 devices, where the link sometimes works and sometimes does not.	No deterministic behaviour; users perceive the feature as flaky.
Expo Updates caching – When using `expo-updates`, a cached bundle may be served that does not contain the latest route files. The deep link will resolve to a missing route.	QA sees the same link working on a fresh install but failing after a hot‑update.	The update process does not invalidate the route manifest.

These constraints are not highlighted in the basic tutorial because they only surface when the app is compiled, signed, and run without the Expo Go wrapper.

The fix, step by step

The following procedure assumes you are using Expo SDK 48, expo-router 2.0.0, React Native 0.71.3, and building with EAS Build.

1. Add the router plugin to `app.json`

{
  "expo": {
    "name": "MyApp",
    "slug": "myapp",
    "scheme": "myapp",
    "plugins": [
      [
        "expo-router",
        {
          "origin": "expo-router"
        }
      ]
    ]
  }
}

Why: The plugin injects the required <intent-filter> on Android and ensures the route manifest is regenerated on every build.

Verify: Run eas build --profile preview --platform android. After the build finishes, download the apk and unzip it (unzip myapp.apk). Open AndroidManifest.xml and confirm the presence of:

<intent-filter>
  <action android:name="android.intent.action.VIEW" />
  <category android:name="android.intent.category.DEFAULT" />
  <category android:name="android.intent.category.BROWSABLE" />
  <data android:scheme="myapp" />
</intent-filter>

On iOS, open the generated Xcode project (ios/MyApp.xcodeproj) and check that MyApp/Info.plist contains the CFBundleURLTypes entry for myapp.

2. Configure Associated Domains for iOS

In the Apple Developer portal, enable Associated Domains for the app identifier.
Add a domain entry applinks:myapp.com.
Host an apple-app-site-association file at https://myapp.com/.well-known/apple-app-site-association with the following JSON (no .json extension, application/json MIME type):

{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appID": "<TEAM_ID>.myapp",
        "paths": [ "/invite/*", "/profile/*", "/*" ]
      }
    ]
  }
}

In Xcode, edit the Signing & Capabilities tab, add Associated Domains, and paste applinks:myapp.com.

Why: Without this, universal links (https://myapp.com/...) are not handed to the app, and the router receives the URL too late.

Verify: Run the app on a physical iOS device, then execute:

xcrun simctl openurl booted "https://myapp.com/invite/abc123"

The console should show:

[expo-router] Initial URL: https://myapp.com/invite/abc123

and the Invite screen should render.

3. Regenerate the route manifest after every change

Whenever you add, rename, or delete a file in the app/ folder, run:

expo prebuild

or, if you rely on EAS, simply trigger a new build. The expo-router plugin automatically runs expo-router generate during the prebuild step.

Why: The manifest is a static snapshot; stale manifests cause missing‑route errors.

Verify: Open the built bundle (.js file) and locate router-manifest.json. Ensure the new route appears, e.g.:

{
  "/invite/[code]": {
    "file": "app/invite/[code].tsx",
    "type": "page"
  }
}

4. Delay deep‑link processing until the router is ready

Create a small wrapper component (app/_layout.tsx) that waits for router.isReady before handling the initial URL.

import { useEffect } from 'react';
import { useRouter, usePathname } from 'expo-router';
import * as Linking from 'expo-linking';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  const router = useRouter();

  useEffect(() => {
    if (!router.isReady) return;

    const handle = async () => {
      const url = await Linking.getInitialURL();
      if (url) {
        // Let expo-router parse it; it will navigate automatically.
        console.log('[expo-router] Initial URL:', url);
      }
    };
    handle();
  }, [router.isReady]);

  return <>{children}</>;
}

Why: Guarantees the deep link is processed after the JS bundle has mounted the router.

Verify: On a low‑end Android device, attach adb logcat and look for the log line above when opening a link via:

adb shell am start -W -a android.intent.action.VIEW -d "myapp://invite/abc123"

You should see the log after a short delay, and the Invite screen should appear.

5. Align Expo Updates caching with the route manifest

Add the following to app.json to force a fresh manifest after each OTA update:

{
  "expo": {
    "updates": {
      "fallbackToCacheTimeout": 0,
      "checkAutomatically": "ON_LOAD"
    }
  }
}

Then, in app/_layout.tsx, clear the router cache when a new update is detected:

import * as Updates from 'expo-updates';
import { useRouter } from 'expo-router';
import { useEffect } from 'react';

export default function Layout({ children }) {
  const router = useRouter();

  useEffect(() => {
    const subscription = Updates.addListener(async (event) => {
      if (event.type === Updates.UpdateEventType.UPDATE_AVAILABLE) {
        await Updates.reloadAsync(); // forces a fresh bundle with the correct manifest
      }
    });
    return () => subscription.remove();
  }, []);

  return <>{children}</>;
}

Why: Guarantees that a newly downloaded bundle also contains the latest route manifest, preventing “missing route” errors after OTA updates.

Verify: Publish an OTA update that adds a new deep‑linkable screen, then install the previous version from the store, open the new link, and confirm the app reloads and displays the screen correctly.

What it costs, and when not to do it

Cost	Detail
Bundle size	Adding the `expo-router` plugin and the associated native code adds ~30 KB to the Android APK and ~25 KB to the iOS IPA (measured with `apktool` on SDK 48).
Build time	The pre‑build step now runs `expo-router generate`, adding ~10 seconds to `eas build` on CI.
Maintenance	You must keep the scheme unique across all apps in the Play Store and App Store, and update the AASA file whenever the domain changes.
Runtime latency	On low‑end devices the extra `Linking.getInitialURL` call adds ~100 ms before the first screen renders. This is usually invisible but can be noticeable on Android 5 devices.
Complexity	The need to coordinate Android intent filters, iOS associated domains, and the JS manifest introduces three separate failure surfaces.

When not to use Expo Router deep links

If your app only needs web‑only navigation (e.g., a PWA), skip native intent configuration.
If you already use a custom native navigation stack (e.g., react-navigation with native screens) and you want fine‑grained control over intent handling, implement the native side yourself rather than relying on the router plugin.
If you must support legacy Android versions (< 6.0) where the intent‑filter schema is unreliable, consider a fallback to a custom scheme handled by a minimal native module.

At your level

Student / first‑year engineer – Verify that the scheme appears in AndroidManifest.xml and that the iOS entitlements file contains the domain before testing any link.
Working engineer – Add the router plugin, regenerate the manifest after each route change, and wrap deep‑link handling in a router.isReady guard.
Senior / staff – Document the three‑point contract (scheme, associated domain, manifest regeneration) in the repo’s README, and set up a CI lint step that fails if router-manifest.json is out of sync with the file system.
Lead / director – Allocate budget for the extra build time and for maintaining the AASA file; treat deep‑link reliability as a non‑functional requirement in the product roadmap.

In the interview

Question (as asked by an interviewer):
“Explain how you would implement reliable deep links in an Expo Router‑based React Native app that is built with EAS. What hidden pitfalls would you look for in production?”

Weak answer:
“Just add a scheme to app.json and use Linking.openURL. It works in development, so it should be fine.”
Why it’s weak: It mentions only the obvious step, ignores native intent configuration, the route manifest, and runtime timing issues. No trade‑offs or failure modes are identified.

Strong answer:

“First, I would add the expo-router plugin to app.json so that the Android manifest receives the proper `<intent

Amit Chakraborty is a founding engineer and senior architect — React Native, AI/RAG systems and production architecture. Portfolio: www.amitchakraborty.dev · LinkedIn · GitHub. Open to senior and founding engineering roles, remote worldwide.

Blocking apps failed for me three times. A daily budget plus a counter of every override has held for 21 days.

Martin Ma — Wed, 21 Oct 2026 02:51:37 +0000

Every screen-time app I tried in 2024 assumed the problem was access. Remove access, problem solved. It is not, and I have the logs to prove it on myself.

The three attempts that failed

Full block, 9 days. I blocked the four apps I used most. Day four I started using the mobile web versions. Day nine I had reinstalled two of them and turned the blocker off "temporarily", which lasted three weeks.

Accountability partner, 5 weeks. A friend held the passcode. I asked for it three times with increasingly creative reasons, got it twice, and stopped asking because asking felt worse than the habit.

Cold turkey, 12 days. Deleted everything, kept it up for twelve days, then reinstalled five apps in one evening after a bad day.

The pattern: every method removed the access and left the reason untouched. A phone is also my map, my messages, my train ticket. "Just don't use it" is not available to me.

What actually changed: budget + counter

Two mechanics replaced blocking.

A per-app daily budget. Games get 20 minutes, short video 20 minutes, messaging and maps unlimited. Not one global hour, which runs out by noon and then gets ignored for the rest of the day.

A counter of overrides. When a budget runs out, the app does not lock. It asks once: continue now, or do the thing you said you wanted to do first. If I continue, it records that. No punishment, no streak to protect, no guilt screen. Just a number that goes up.

The counter is the part that worked, and it is the part every blocker I tried was designed not to have. Blocking is binary: you are compliant or you have failed. A counter is a measurement, and measurements are harder to lie to.

21 days of data

I logged every open and every override from 1 to 21 October.

Sleep-adjacent phone use: 90 min/night to 12 min/night
Opens per day: 41 to 19
Overrides per week: 23 to 6
Apps uninstalled: 0

The 23-to-6 drop is the interesting number. I was not overriding less because I had more willpower. I was overriding less because overriding had become visible. Seeing "23" next to a week made the next override feel like a choice rather than a reflex.

Why the "no stopping cues" framing matters

Short video, games and social feeds share one structure: no natural end. A season never ends, a feed never refreshes to a bottom, an autoplay queue always has a next item. So the useful question is not "how do I stop" but "where do I put the stopping cue".

Three cues that survived contact with a bad day:

A budget boundary — an external, pre-committed end that is not a judgement about me.
A single question at the boundary — one prompt, not a wall of options.
A visible count of crossings — the only feedback that changed behaviour without shame.

What I built, and what I left out

I got tired of stitching this together across three apps, so I built it as one: per-app budgets, one prompt at the boundary, and a plain counter of overrides, all stored on the device. It is called ChoiceField, iOS only, free.

Two deliberate omissions, because I think they matter:

No blocking mode. A block that can be bypassed teaches you that rules are optional; a budget that reports does not.
No rankings or streaks. Streaks punish a bad day twice: once when it happens, once when it resets.

If you want to look at it: App Store (US) or App Store (China).

If you only take one thing from this: stop trying to remove access, and start making the override visible. You can do that with a notebook for a week before you install anything.

Apple Watch Ultra 4: Everything the orange action button can do

Hacks.gr — Wed, 21 Oct 2026 02:35:32 +0000

The Apple Watch Ultra 4 expands its hardware utility with the introduction of the Action Button, allowing users to bind custom commands to physical input.

The button integrates with the iOS Shortcuts framework, enabling complex automation sequences.

Additionally, the device leverages watchOS 27 to allow shortcut creation through descriptive input and introduces Audio Intelligence for music recognition, providing a more robust interface for wrist-based computing.

How the action button works

You can set the button to perform a specific action with a single press, such as opening the flashlight, taking a voice note, translating a phrase, or recognizing a piece of music with the watch's instant audio recognition feature. If you hold the button down, a menu appears to quickly change its function.

For those who play sports or go outdoors, the button instantly controls workouts, timers and dives. It also supports navigation functions, such as recording specific points and returning to the route. In case of emergency, the same button can activate a siren to attract attention.

One-touch automations

The action button can be linked to the Shortcuts app on your iPhone. This lets you perform automated commands, such as controlling smart home devices, with a single tap on your watch.

AI Questions Were Scattered Everywhere, So I Built Approval Box to Collect Approvals on My Phone

Quo — Wed, 21 Oct 2026 02:15:34 +0000

This article is a repost from I Started Using Claude Code.

I released an iPhone app called Approval Box on the App Store. It's an app that lets you receive consultations coming from AI running on your PC on your phone, and answer them on the spot.

Questions get scattered all over the place

When you work with AI, you end up opening a lot of sessions. I also use multiple tools (harnesses) to run AI. As development goes on—and not just development, but any kind of work—the AI in each session starts asking questions. The questions get scattered all over the place, and answering them becomes a chore.

I often step away from my computer. If the AI asks a question while I'm away, that session stops and waits for an answer. Before I know it, the work has ground to a halt.

Approval Box was made to solve that.

Approvals from many sessions gather on your phone

When AI needs a human decision or approval, it submits a request to Approval Box. Requests gather in the phone app, and the subject arrives as a push notification. The app lists which AI it came from, what work it's about, whether it's urgent, and when it's due.

The inbox screen. Consultations from Claude Code, Codex, and Grok are lined up in a single list.

When you open a request, the background and options written by the AI appear. The AI's recommendation is marked, so you can choose while looking at it and send your answer. Besides the options, you can also write instructions in text, or attach images and documents in your reply. If you can't decide right away, you can put it on hold and answer later.

The consultation screen. Read the background, look at the AI's recommendation, choose an option, and send your answer.

When you answer, even sleeping sessions wake up

The amazing thing about this app is that once you send an answer, even sleeping sessions wake up. The answer goes straight back into the conversation of the AI that submitted the request. If the AI is working, it reaches the current turn; if it's stopped, it arrives as a new turn, and the AI continues the work from there. Answer from your phone, and the work resumes on the spot.

Another feature: the AI itself can withdraw or update an approval request. If circumstances change after submitting a request, the AI can revise the content or withdraw a request that's no longer needed. The app reflects this directly, so the list keeps only the consultations that need an answer now.

In the history, you can check whether your answer reached the AI. I also added a feature to copy a "nudge to resume" for when you want to continue the conversation.

The history screen. Answered consultations and whether they reached the AI are lined up.

It's easy to use

Run the following command on your PC.

npx -y approval-box@latest setup

It will find the AI on your PC and register Approval Box for you. It shows you the files it will modify first, keeps a backup, and then makes the changes. After that, just scan the QR code shown on screen with the app, and your PC and phone are connected.

The add device screen. Run the command on your PC and scan the QR code with your phone.

Finally, ask the AI to "run Approval Box's setup_test." A test request will arrive on your phone, so answer it, and if the answer reaches the AI, you're all set.

The supported AIs are Claude Code, Codex, Cursor, and Grok, and the PC can run macOS, Windows, or Linux. The PC side requires Node.js 20 or higher.

The app can be downloaded for free, and the official service's monthly plan is 300 yen in Japan. A separate contract for the AI itself is required. There's also a web version you can use in a browser, and usage instructions are compiled on the support page. The server and web version code are published on GitHub, so you can also host the server yourself.