Four iOS Features, Ten Years On: Which Ones Survived

PixelForce Updated 5 min read
Four iOS Features, Ten Years On: Which Ones Survived

iOS 10 gave developers four new ways to reach users outside their own app: iMessage apps, Apple Pay on the web, SiriKit and CallKit. Ten years on, two of the four are still load-bearing, one has been formally deprecated, and one never became a channel worth building for. This is the honest scorecard, and what it means if you are planning an iOS build now.

We published the first version of this article the week iOS 10 shipped in September 2016. Keeping it accurate a decade later is more useful than deleting it, because it documents the pattern that actually decides what an app should be built on: Apple opens an integration surface, developers commit engineering budget to it, and only some of those surfaces are still there years later.

The four iOS 10 features, scored ten years later

  • SiriKit - deprecated. Apple formally deprecated it at WWDC in June 2026. New Siri work goes through App Intents instead.
  • Apple Pay on the web - still current. The widest-reaching of the four, and the one most businesses actually use.
  • CallKit - still current. Still the supported way to put voice over IP calls into the native call interface.
  • iMessage apps - still supported, but marginal. The framework works; it never became a distribution channel.

SiriKit is deprecated and App Intents is now the route into Siri

This is the change that matters most to anyone maintaining an app built in the iOS 10 era. At WWDC in June 2026 Apple formally deprecated SiriKit, the framework this article introduced in 2016, and made App Intents the framework through which an app exposes its actions to Siri. Existing SiriKit integrations still compile and run, with deprecation warnings in Xcode, and reporting from the announcement points to a support window of roughly two to three years before removal.

The original version of this article named SiriKit's real limitation at the time: your app had to fall inside one of six Apple-defined categories - messaging, ride sharing, photo library, peer to peer payments, workouts, and climate control and CarPlay radio - and we wrote that Apple had said it would open more categories in future. That is the promise that never fully arrived, and it explains the replacement rather than contradicting it. App Intents is not a fixed vocabulary of domains. An app declares its own actions with typed parameters, so the framework no longer has to anticipate what kinds of app exist.

The practical consequence is that App Intents is not only a voice feature. The same declarations feed Spotlight, Shortcuts, widgets and the system action surfaces, so the migration buys more than Siri. If you shipped SiriKit intents, treat the move as scheduled work rather than an emergency - but schedule it, because the deprecation clock has started. The interaction design is its own discipline: see voice interface design for why a voice action is not a screen with the pixels removed.

Apple Pay on the web is the one that paid off

Apple Pay on the web is still current and has the widest reach of the four. Safari supports two JavaScript APIs for accepting Apple Pay payments on a website, and Apple runs a web merchant registration process for e-commerce platforms and payment service providers, so most mainstream platforms and gateways support it without custom work.

What has changed is how we would phrase the benefit. In 2016 this article said online retailers could “expect more conversions”. That was speculative then and we would not write it now. What is defensible is the mechanism: Apple Pay removes card entry and address entry from the checkout, and a checkout that asks for fewer fields is abandoned less often. Whether that shows up as a conversion lift on your store is a question for your own analytics rather than for a blog post. If you are deciding how to take money at all, start with payment gateway integration rather than with a single wallet.

CallKit and iMessage apps: same era, opposite outcomes

CallKit has aged well because it does one job and does it completely. An app that carries voice over IP calls can route them into the iPhone's native call interface, so a user answers or rejects a call the way they answer any other call, without opening the app. That was worth building in 2016 and it is still worth building now, for the same reason: it removes an unfamiliar interface from a moment where users have no patience for one.

iMessage apps are the counter-example, and the more useful lesson. The framework is still supported and still shipping, but the channel never materialised. At launch the iMessage App Store carried more than 1,650 apps, the majority of them sticker packs, and that mix never fundamentally changed. The honest advice a decade on is to treat an iMessage extension as a convenience for users you already have, not as a way to acquire new ones - and to size the investment accordingly.

What this means if you are building an iOS app in 2026

The lesson generalises well beyond these four APIs. Integration surfaces are where an iOS app stops being a website in a wrapper, and they are also where platform risk sits, because Apple owns the roadmap and can retire a framework you have built on. Three questions are worth asking before committing budget to any of them:

  • Is this surface load-bearing, or a nice-to-have? CallKit is load-bearing for a calling app and irrelevant to everything else. Build the ones your product would be worse without.
  • What is the exit cost if Apple replaces it? SiriKit is the worked example. Teams that wrapped their Siri handling behind their own interface have a contained migration; teams that let the framework shape their architecture have a project.
  • Who maintains it after launch? An integration is not finished at submission. Someone has to be watching each June when Apple announces what is changing.

PixelForce has built on Apple platforms since 2013. We have won more than 30 global awards, including Apple Best of Developers, Apple Watch App of the Year and Apple TV App of the Year, and we hold a 98 percent first-time app store approval rate. Revia reached number 3 in Apple's Health and Fitness category within 48 hours of launch, after a four-month build. If you are working out what an iOS build involves, our iOS app development page covers how we scope one, and how long it takes to build an app covers realistic timelines.

What changed since this article was first published

This article was written in September 2016 and revised in August 2026. Rather than quietly deleting what is now wrong, here is what moved:

  • SiriKit was deprecated in June 2026. The six-category restriction described in the original never expanded as Apple indicated it would; App Intents replaced the model instead of extending it.
  • The conversion claim has been withdrawn. The original said retailers could expect more conversions from Apple Pay. The mechanism is real, the promised outcome was never ours to guarantee.
  • Touch ID has largely given way to Face ID on current iPhones, so the authentication step described in the original now looks different on most devices even though the checkout flow is unchanged.
  • The iOS 10 interface screenshots have been removed. They showed a version of iOS no reader is running, and they were hosted outside our own infrastructure.

Frequently asked questions

Plan it now, execute it in your next scheduled release cycle rather than as an emergency. SiriKit apps still compile and run after the June 2026 deprecation, and reporting points to a support window of roughly two to three years, so nothing breaks tomorrow. The reason not to wait is that App Intents is where new capability lands, so a delayed migration is not only a maintenance debt - it is capability you are not getting.

Very likely yes. App Intents is not only a Siri framework: the same action declarations feed Spotlight, Shortcuts, widgets and the system action surfaces. An app that declares its actions becomes reachable from places the user already is, without opening the app. That is worth doing on its own merits even if nobody ever speaks to your product.

As an acquisition channel, no. The iMessage App Store launched with more than 1,650 apps, the majority sticker packs, and it never became a place where users discover software. As a feature for users you already have - sharing something from your app into a conversation without leaving it - it can be worth a small, contained investment. Size it as a feature, not as a growth strategy.

No. Apple Pay on the web runs through JavaScript APIs supported by Safari and does not require you to ship an app. You do need to complete Apple's web merchant registration, which most e-commerce platforms and payment service providers handle for you. An app changes what else you can do - push notifications, offline use, native integrations - but it is not a prerequisite for taking an Apple Pay payment on the web.

It depends almost entirely on how the original integration was written. If SiriKit handling was wrapped behind your own interface, the work is to re-express each supported action as an intent and to test the phrasings, which is contained. If the framework was allowed to shape the app's architecture, the migration reaches further into the codebase. The honest answer is that this is a scoping question rather than a fixed number, and it is the first thing to establish before committing to a date.

Keep reading