App Clips for iOS | Hacker News Reader

App Clips for iOS

developer.apple.com

190 pointswodow172 comments

I'm excited for what this means for categories of apps that many users currently consider to be "junk" – restaurant ordering apps, parking apps, venue apps.

There are many of these, and we often don't want download these, or when we finally cave in and do download them the friction of notifications and eventual deletion is a pain.

With App Clips, and some of the features like "no install", 8 hours of push notifications and the ability to confirm a fixed location without location permissions, I think the UX is going to be significantly improved.

A while back, there was an attempt to build a web-based solution to this problem. It was a card-based browser called Wildcard (their page is dead so posting an article)

https://techcrunch.com/2014/11/13/wildcard-raises-10-million...

It seemed like a really cool idea, shame it never took off.

that looks similar to google's "physical web" project from 2016, which was apparently just as successful.

https://blog.chromium.org/2016/02/the-physical-web-expands-t...

What incentive do parking and venue apps have to implement this? The audience is captive. They push the app because either they do not want to spend the engineering effort to make a usable website or they want to siphon data from their clients. In either case, they will not have an incentive to spend more engineering time to get less data from customers.

It seems within Apple's style that they will eventually require this to be implemented for certain types of apps.

Can they, though? It seems like a lot of the use cases for App Clips depend on physical infrastructure being added in the real world, like the NFC sensors that project the existence of an App Clip. Apple likes to control, but I don't think they can really compel physical infrastructure.

You don't need any physical infrastructure for using App Clips. Ultimately they are launched via URL - that can be by physical NFC tags or QR codes, or just via Safari, a SMS/iMessage, etc.

Why is this downvoted? This comment is spot on. The junk apps are junk because the businesses make them like that on purpose.

You can also turn this around: what stops businesses right now from making extremely lightweight apps that don’t bother the user? The same forces that make companies slap tons of trackers and JS on their websites.

> The junk apps are junk because the businesses make them like that on purpose.

While this is sometimes true, I think it's more often the case the businesses make junk apps because they pay the lowest bidder to make them a bare minimum app.

And the lowest bidder is often an app factory.

See real estate apps or corporate travel apps for instance. A majority seem to be the same few practically unusable apps re-skinned.

I believe as part of the App Clip announcement they were showing Yelp creating/managing apps for restaurants. So they're specifically trying to improve this type of app.

I wouldn’t assume that’s the only reason for how these apps exist. Most businesses pay considerably more for an app than it would cost to have a website. In some cases that’s due to something like robust offline support or tracking not allowed by the web security model but there are plenty of more common reasons: the owner wanted to be able to tell their friends that they’re in the App Store, they perceived it as more modern/cooler, they got a sales pitch about how this would boost revenue or customer loyalty, etc.

One way to guess about what’s happening is to look at the app quality and update history: if it looks like it launched in the original App Store round or has a hideous UX which is never improved, it’s probably not actually doing enough to be worth spending more money on.

Exactly. I’m not a huge fan of Yelp but I used to use the mobile website occasionally. But they have been slowly crippling the mobile website over the years to force you to download the app instead. So now I don’t use Yelp anymore. I don’t see why a company like Yelp would embrace this, although given Apple has featured them extensively in the announcement I assume they are embracing it after all. Maybe because there’s such a simple path from app clip to installing the full app, companies might see this as a potential avenue for new installs? Also supposedly App Clips can access nearly all of the native app APIs, so even if they can’t get much location data and have limited notification access, they might be able to get some available data off the user’s device?

>companies might see this as a potential avenue for new installs

it seems like the opposite of that to me. right now, if there's some task you want to accomplish (order a meal, rent a scooter...) you have to install the app to do that. With app clips, you get the option of completing the task without installing the app. as a user i love this, but it's definitely not going to drive app installs.

I agree, I was mostly trying to play devils advocate and try and figure out any potentially positive reason. As an extreme counterexample, I refuse to install GrubHub or Uber Eats or apps like that, instead just calling the restaurants directly to order food. It’s possible I might try out an app clip, and maybe the process would be smooth enough that I’d be willing to upgrade to the full app. But I know I’m definitely outside the norm and realistically this wouldn’t move the needle in a positive direction for businesses.

I’m mostly just concerned that this will likely detract even further from web-based alternatives. GrubHub might decide that since they have App Clips, they can pull a Yelp and disable their mobile website completely.

> What incentive do parking and venue apps have to implement this?

Because Apple is known to kick apps out if they don't like them?

Go visit mainland China and see how QR code’s exist everywhere that lead to mini-apps inside of WeChat. There’s plenty of precedent.

Maybe apple might stop approving junk apps that do not implement clips, like they ban apps that have "sign in with XYZ" but not "sign in with apple"

(this post represents my opinion only, and does not speak for my employer, my cat, or the flying spaghetti monster)

I think maybe Apple can force them to do it somehow. And for all the other cases like ordering food, renting scooters, bikes, entering the gym for a one off session I think it’s just going to be competition. If lime has an app clip and bird doesn’t I’ll walk the extra 15 minutes. I did ask quite a few ppl since the announcement and most friends said they just dislike the new service signup soooo much they would be willing to do a physical sacrifice.

Edit: definitely not claiming this will be a mass thing but it’s my gut feeling it would be.

+ it’s a less friction conversation of very difficult segment of customers. That might count for something for some companies.

> What incentive do parking and venue apps have to implement this?

As a good example, a parking meter app is simply there to collect money at the meter. An App Clip is small, which will be way faster to download than the full app, and enable a user to pay much faster than before. In a situation where you want people to get an app but know that they're time constrained and that app is how you get paid, you'll implement it because it'll make sense to implement.

I've personally given up on bike and scooter rental apps because the time to download and setup was frustrating. For those cases, this would be awesome.

But as mentioned, the audience is captive. If there was another parking option around the corner they would have used that. I don't think parking lots care how long it takes you to download their app and pay.

Not really, there are often other options. Different lots nearby using different systems, for instance. Or the option of simply not paying and risking getting towed / a ticket.

A parking lot clip could use the time-based notification to warn you that your meter is almost up and give you the option to re-up. Without having to walk back to the lot to do it. I imagine this would be especially useful in a tourist-heavy area since somebody who isn't sticking around won't want to download a whole app for the purpose.

I kinda doubt that parking lot management companies would be willing to pay Apple's 30% transaction fee though.

Apple's fees are on digital goods, not physical ones. Amazon doesn't pay a fee for me to place a physical order in the Amazon app, nor does the laundry app in my old apartment building.

I thought parking counts as a service, not physical goods, but then again I think I paid parking via app in the past, with external payment gateway, so you're probably right.

The in-app purchase system is the one which takes a fee, and is only sometimes required (and only _usable_) for services or digital goods consumed in the app itself.

Any real world good or service would fall onto Apple Pay, which makes its money through a micro fee on the card issuer, basically to use the phone as a convenient, highly fraud-resistant card.

There's usually a non-app payment alternative.

You're also looking at this the wrong way. Parking apps make the overhead of managing parking lots less expensive. IF you have higher adoption of the app you have less problems with your onsite machines/attendants/cash. Those cost way more money than adopting this across your fleet of lots. Also a lot of lot owners, have a mangement company or work with an app vendor who will add this as a simple way to improve their cash flow.

App vendors are only paid by the people who use the app, so they have every incentive to make it that much easier for some one to use the app than the ticketing machine.

The parking lots may be competing with other lots, but really they are most likely getting money either way, they want to decrease their overhead, hence apps.

But the parking lot can just require the app. That’s the point. They do not need to worry about adoption of the app because you need the app to use the parking lot.

They can up until someone says they don't have a smartphone or their battery is dead.

The reality is that most parking lots do need to have fallbacks for these cases rather than telling people to drive off, and those fallbacks are often more expensive in terms of staffing/maintenance (which is why they added the app in the first place). Something where I point at a code on a sign, it pops up a payment button without me knowingly downloading anything will increase the cost savings beyond an app.

They also, cleverly, give you an easy way to convert the Clip into the full App right from your home screen. I think certain segments of dev companies will love this as an avenue for onboarding.

So that I use their service instead of passing on it?

Agreed. Google did something similar with Android a few years ago and I haven't come across an app that takes advantage of it yet.

Businesses want to offer apps so that they can collect more information on their customers, not because an app is the best solution to the problem at hand.

Unless they refuse all other forms of payment, this keeps all of the many app problems from pushing into manual paths requiring human time to correct. Each stage of the process has people dropping off and calling for support or talking to an attendant.

I actually LOVE this idea. And we develop an app for people to get personalized information from their local government (https://polkadotskysoftware.com).

What I love is that we actually get access to a whole swath of people that want quick information but don't want to install a whole app for it. In fact, we want to make our stuff available on any platform, because our goal is to get as many people to use our system as possible.

When it comes to parking vendors, they get their money no matter what (either from a government contract or as a slice of parking fees, not from number of app installs), so it's in their best interest to INCREASE engagement.

Our main problem is that our mobile app is written in React Native, so I'm not sure how this would fit in near-term. We are loathe to add too many native features because the whole workflow in React Native is already a bit brittle.

OT, but your company looks really interesting. It's similar to a project idea I had recently but hadn't explored yet.

A few questions: are you a nonprofit? And if not, who do you sell to? Do you sell to local governments to help them quickly bootstrap citizen involvement services? Do you develop solutions on an area-by-area basis or do you have a single product that tries to cover all of them?

We're a for-profit that sells a SaaS product to (so far) state and local governments. Our stack is Elixir and Ember JS, running on AWS.

We're currently involved in a lot of COVID related efforts in the eastern US (SMS delivery of test results, etc – we haven't had a chance to update our page, been too busy). Still a product but each customer has custom needs to integrate with their systems, which we do via APIs and custom data ingestion code.

We do guide local governments in bootstrapping all the data on our platform but it's a multi-tenant system and everyone's on the same platform.

Yeah, good luck making it under the 10mb limit with React Native.

I'm excited for what this means for categories of apps that many users currently consider to be "junk" – restaurant ordering apps, parking apps, venue apps

I have an old iPhone that serves a particular task in a closet and I almost never interact with it.

Earlier this year I needed to do something physically with it, and noticed it was filled with dozens of parking, ride hailing, taxi, and transit apps I'd downloaded on my main iPhone over the last few years. (For those of you not in the iOS ecosystem, if two devices are on the came iCloud ID, downloading one can download the app to all of your devices.)

With app clips, I won't have to go through and delete all these short-time-use apps on all of my devices when I get home from traveling.

Edit for all those replying without understanding my situation: I don't want to disable app syncing entirely. Some apps I want to be synced on all of my devices. It's the one-time or short-term use apps I don't want. The ones that Apple is targeting with App Clips.

This is a very easy setting to disable in your iCloud account.

It is, but I don't want to disable it. Some apps I want to be synced on all of my devices. It's the one-time or short-term use apps I don't want. The ones that Apple is targeting with App Clips.

This feature can be turned off. Search for “automatic downloads” in settings.

I'm excited for this too and I was very excited a couple of years ago when Android launched instant apps which were the exact same idea, but they never took off. Hopefully with Apples tighter control of NFC in their phones and better marketing they will become more prevalent.

Even for interacting with your robot hoover or your headphones there's plenty of opportunities to create much better user interactions than your first step of onboarding to involve going to an app store.

In my experience a lot less money comes out of Android, and feature parity is extremely important. If iOS didn’t have the equivalent feature, there was often no significant advantage to utilizing them on Android.

This feature was created in the vacuum left by the slow and stale nature of web standards organisations. There should be a safe, simple way to develop a website that has all of these features. This would allow functionality like this to exist on platforms outside of Apple's control.

Websites support Apple Pay, sign in with apple, being loaded from a URL/NFC/QR code, location API access, etc. The main thing websites don’t support is push notifications on iOS, and it seems like that would be a lot easier for Apple to implement then an entirely new app format. I don’t think you can really blame web standards organizations, this is entirely Apple’s decision. They want their proprietary App Store front and center.

> slow and stale nature of web standards organisations

If there's one thing I've never heard the web platform accused of being, it's "slow and stale".

The web platform has plenty of features for doing this kind of thing. It already partly serves this use-case, in practice. There are two reasons Clips will have an advantage:

- Apple has done a lot to hamper Progressive Web Apps on its devices because they have a stake in platform lock-in.

- The web, at least on mobile, is still never quite as good an experience as a native app. There are lots of fingers that can be pointed at different parties for why this is, but speaking as a web developer, I will readily admit that it's just not quite the same on some subconscious level.

Whats the incentive for these apps to make clips available? Why wouldn't the parking app you hate just keep forcing people to install it, likely to track and report as much data as possible as an additional revenue stream.

Competition: if enough apps will implement it, it would become a standard user expectation.

Not every audience is captive. If Lyft offered this and Uber didn't, it might be a subtle push for me to prefer the former. Or maybe even walk/bike if neither adopts it.

I see a very good business case for this for some companies. Think of uber or lime, there is very little user data can do for them, whereas instant availability has enormous potential to boost their business. Right now either a user has all the scooter/ride-hail apps or one or two. Every time a user looking for a scooter passes one they don’t have an app for, that’s lost business for them. If app clips allows users to use whichever scooter is closest to them it can drive overall usage way up.

Well maybe not Uber, but for sure for things like scooter or bike sharing. Now that I think about, do people really want to touch a bike or scooter that’s been lying around given potential exposure to Covid? Anyway I think there will be plenty of use cases for App Clips. And to add to that, I think Android/Google has had the Instant App feature for some time now, it’ll be interesting to see what sort of opportunities arise from this App clip/Instant App ecosystem.

Covid doesn't appear to transmit easily (or potentially at all) via surfaces.

I agree, though I think there's also a more cynical side to it. I see it as a land-grab by Apple to bring use-cases that currently belong to the web, under the umbrella of their app ecosystem. I'm still excited because I think the user experience will be legitimately much better. But I am a bit concerned about the implications.

Any time I try to order food on the web I feel like I have to make an account for some service I've never heard of and manually enter in credit card info. I fully welcome just being able to choose my order and pay with Apple Pay, nothing else needed.

Sign in with Apple and Apple Pay already exist on the web. Though I guess, Apple can't force companies to offer it on the web.

That's an option on the web too though? Through both Apple's proprietary implementation and the standardized Payment Request API: https://developer.apple.com/documentation/apple_pay_on_the_w...

...of course this requires developers to use it, but then so does App Clips.

Apple has a policy that any app developer who offers "Sign in with ___" for any company, has to also include "Sign in with Apple". That's not something they could do on the web.

They could revoke your keys (in theory). I don't think they would though

You misunderstood; I'm saying Apple couldn't coerce a website into offering Sign in with Apple as an option, like they can with an app on the App Store.

And they are saying that apple can do that. By threatening to revoke payment keys.

What kind of payment keys would they revoke for a website that does not offer ‘Pay with Apple Pay’?

To me, this is a feature: I don’t want to have a million passwords because some random developer doesn’t like my preferred authentication method. As a user, I prefer to pick a trusted authentication provider and use it everywhere because, in the end, it’s a lot simpler for me: I don’t need to remember half a million username/email/password combinations, I just need to be able to authenticate myself to Apple.

Developers, web developers especially, often seem to forget that the browser is a _user_ agent. Instead, they force their aesthetic and functional preferences on me, when I have chosen fonts, colors, interactions and systems that I prefer to be able to use wherever possible.

When Apple announced App Clips, it sounded like something I had seen in A16Z briefings -- people scanning QR codes on super-apps in China. It seems that Wechat has the concept of Mini Apps which are similar (but less seamless than Apple's App Clips).

https://www.scmp.com/abacus/tech/article/3090269/ios-14-adds...

This is really to cut down on Google searches.

In fact, if you go through many of the features in iOS 14 they are designed to let you do things without having to Google for information/links to do it.

I’m not sure why this isn’t highlighted more often, but I don’t see this just as a take on making web apps less relevant for iOS users.

Rather what I see is a system to take on and take back control from the “app in app” WeChat ecosystem that has taken over so many parts of everyday life in China.

It seems to me that Apple is looking to replicate that success, and sees the potential for apps that users don’t want to keep around permanently.

It is indeed sad that this may discourage companies further from building solid web apps, especially if Android counters this system with their own, but I think it’ll mainly be interesting to see if and how it’ll affect WeChat in China.

Android actually already has something similar: https://developer.android.com/topic/google-play-instant

Not similar. It is absolutely the same.

Only Google Android, neither my current nor my previous phone have had the option to use instant apps.

Maybe it's a region lock thing (I'm not in the US) but it's not globally available on all Play Services devices so I don't know what the point of putting effort into Instant Apps really is. It only makes sense to support all of Google Android or none of Google Android.

It’s great to see that that’s already supported! I wasn’t aware of that, and it’ll allow Google to pivot this feature towards a similar use-case.

Right now however it seems to primarily be marketed to mobile game developers.

I'm gonna be the web guy... have we given up on the web completely? Why not improve the signup/payments experience using Web APIs? Why not integrate safari more closely to what is required with these App Clips?

It seems the only real reason that Apple isn't doing this is because it wants people to build for their App Store so they have control and possible revenue stream.

From a dev perspective this feels like a lock-in: yet another platform to support

> It seems the only real reason that Apple isn't doing this is because it wants people to build for their App Store so they have control and possible revenue stream.

You say it incredulously as if that’s not a valid reason. Of course that’s the reason. Money is the reason why most companies do things.

All the cynical comments about Apple's ecosystem motivation certainly apply, but there's one much more mundane reason: UX.

The best PWA still feels vastly worse than native versions (my reference is Twitter) and for Apple that's a huge factor, which I respect a lot.

I'd also add reducing friction. It seems the goal here is to reduce the amount of time it takes to get the user to the exact functionality they need in the shortest amount of time with a user experience that makes it feel seamless.

A QR code is exactly the same thing. If you wanna talk NFC... how many people do you think are gonna buy apple's proprietary NFC broadcaster? either way though apple could use the same API to call a public website instead of a private call to a handicapped app.

They're still downloading MBs of data. Not sure how big most websites are these days but I would surprised if most app clips don't go right up to that 10MB limit.

Web = Google Searches. Apple doesn't want you to do that anymore.

This will be really useful when the AR goggles launch. And for interesting AR or other fun (but ultimately throwaway) experiences before that.

There's so much cool stuff you can only do with an app but currently there's just too much friction. I hear someone say "No one downloads apps anymore" daily. Well, now they don't have to, and we can still make the fun thing we want to.

The 10 MB limit is going to be very interesting, because it would instantly preclude the use of many SDKs that apps bundle these days "as a given". Unless there's a massive shift, things like Facebook login and analytics frameworks are just not going to work…maybe it'll cause developers to drop them from their full apps as well?

As a native Swift developer, I can live with this.

I used to spend a lot of time, optimizing 8-bit images (PNG8), but gave it up, some time ago.

This looks like I may want to revisit that exercise.

Perhaps that's why Xcode 12 supports SVGs now. Supposedly on iOS 13 they won't rasterized during build.

Yay!

I've heard that SVG has been supported for a while, but I have not used them (yet).

If anything it will force analytics SDK makers to make their code leaner. I find it hard to believe that analytics SDKs need to be so bloated.

And I think the goal is to get users creating accounts with Apple Sign-In rather than Facebook. IMO it's a perfect use-case. I don't want to give away sensitive personal information to these "throw away" apps, I'll create a temporary account with Apple instead.

IMHO both this and the Android Instant Apps are half assed ideas.

The ultimate goal should be working towards having the ephemeral nature of web apps while maintaining the native app performance. That is, access to raw sensors, running native code rather than JS and working offline. I know it's technically challenging but that should be the direction.

How is downloading a < 10MB native instant app any worse than downloading a frequently-larger web app?

> ...a frequently-larger web app

Got any stats for that? I was quickly able to find [0] and [1] which state that web page sizes are 1.5mb (median), 2mb (mean) and the average is about 3mb.

[0] https://royal.pingdom.com/webpages-are-getting-larger-every-...

[1] https://speedcurve.com/blog/web-performance-page-bloat/

Are those web apps or web pages though? Like I don't think blogs are what OP had in mind.

I'm not sure, that's why I'm asking for clarification. I'd like to know where the OP got their "frequently larger" stat from because I wasn't able to find one that specifically used the term "web apps".

Is there a functional difference between "mean" and "average"? I've always thought that they're the same thing.

Yes, they are. I was repeating the terms used in the respective articles.

> That is, access to raw sensors, running native code rather than JS and working offline.

So, a native app?

GP wants web apps that feel native. I'm not sure that'll happen mid-term.

If you'd asked my 5 years ago I would have said the web would dominate. Now I'm not so sure (although I'm also currently working in mobile). It feels like by the time we get to something like webapps that feel native they may not really be webapps anymore, maybe something like what google is doing with Flutter or something WASM based that can run on anything.

No, native apps UX comes with installation, worrying about it wasting the device resources and ultimately uninstallation. The distribution is also centralized through App stores rather than self-hosted web sites.

Both PWAs (using web app toolkit) and Instant App / App clip are trying to fill the gap across web and native apps but both seem like band-aids.

So a more concerted effort seems necessary. I remember Google's Fuchsia was working towards such a thing but idk how much progress they've had.

> the ephemeral nature of web apps while maintaining the native app performance

...that's... what this is?

I'm curious what Apple Pay and App Clips means for the ongoing browser wars and the web in general. The more and more Apple or Google create products that only work with _their_ hardware and _their_ browsers, where does that leave everyone else?

Imagine scenarios like:

- Want to use Apple Pay on your laptop? You'll need Safari!

- Want to redeem a reward off a QR code in a store with your friends? If you switch to Safari right now, no problem!

- Want to pay your parking meter in a rush? Safari has you covered!

I'm aware of Google Play Instant, and I assume that App Clips will only accelerate the adoption of both technologies. But will they be adopted at the same rate, or with the same quality?

And where does that leave the users? The web was wonderful in that, as long as you can access a website, you can have a (hopefully/roughly) similar UX. Now it feels like that semblance of access is being eroded with more ecosystem lock-in.

Is it possible to open this up?

Apple Pay can be exposed with the Web Payments API implemented by every web browser. If you use the API, it’s exposed by each platform using its own payment standard.

Reminds me of ActiveX in the late 90s/early 2000s...tons of web applications developed exclusively for Internet Explorer on Windows. As a Mac user in high school/college at the time, I occasionally had to use the shared computers in the school library just to use certain web apps that were built with ActiveX.

I thought App Clips were the most exciting part of iOS 14. I think there’s a real opportunity to utilize this for some guerrilla marketing (I hear a lot of it will work through deeplinking). It seems like a lot of it will be purchase intent based, but I can also imagine once Yelp implements this, you can deeplink to a 5 star rating. A Soundcloud rapper can now have folks scan into their new song and get a preview.

Let these companies build the integrations and find creative use cases around them!

Given how often I encounter very broken deeplinks on iOS, this doesn't make me especially optimistic if there will now be another layer to it...I regularly click links on my iPhone that dump me into the app store despite already having the app installed, or that will open the app for a brief moment, only to switch me back into Safari, or banners on products/posts/pages that prompt me to "View in App" that just don't actually work properly.

I haven't personally worked on an app with deeplinks in a few years, so I'm not sure what's going on, but it seems to be a widespread issue.

> Instead of asking for credit card information, you can take payments using Apple Pay.

But can I ask for credit card information and not use "Apple Pay". The "instead" is super weird there.

Also, why not just PWA ?

Because if it's a part of a native app you can later download the "rest" of the app and it still has all your data already.

But can I ask for credit card information and not use "Apple Pay". The "instead" is super weird there.

"Apple Pay" doesn't mean Apple Card. You can have a bunch of different credit cards loaded into Apple Pay.

Also, why not just PWA ?

I hope companies go with this instead of PWA for the simple reason of bloat. Apple's payload restriction on App Clips is something like 10MB. Most PWA's blow that cap loading the page header and footer.

I guess if they put a restriction on pwa size, people will make them below 10 mbs. Right now there is no restriction on pwa size as such. and I am sure the size isn't the reason for going with this and not pwa.

It's not like something won't allow those App Clips to download 100 MB after launch.

They are limited to 10 megs of storage space. Unless you download the real app they can’t do that.

Sure you can do a PWA. But if you're doing e.g. a ticketing/parking app - it might just be worth paying the ApplePay tax to go with the friction-less experience for your app clip.

You could make it easy to do ApplePay, and also have a "enter CC in the main app" approach.

There is no fee (except, rumored, to the issuing bank) to accept Apple Pay for physical world purchases, beyond the normal credit card merchant fees.

You may be thinking of the fees associated with in-app-purchases?

My bad - I could swear Tim saying they'd adopt a small transaction fee for Apple Pay when it was released.

I find the wording of this odd also. They mention Apple Pay and Sign in with Apple, but also say App Clips can use the full SDK. Would you not be able to include the Stripe SDK or a competitor?

Doubt it'd fit in the 10 MB

> Also, why not just PWA ? Apple won't get 30%. They'd have to put effort into making PWAs work reliably, which they don't want, and they'd open up the opportunity to get real app-like experiences without the 99 dollars per year + 30% of sales.

There's no incentive for Apple to support this because they can only lose money. If they do release it, they'll probably make you pay for something to use all of the APIs, like for a messaging platform or for access to certain entitlements for full sensor support.

Apple doesn’t get 30% of sales of physical goods. Do you really think $100 a year is any motivation to Apple?

Ah. The good old times when you tried to squeeze your game into 10mb, optimize the hell out of it, so it was downloadable over cellular. These days apps are humongous without good reason

So for Apple it's OK that you download a temporary app from a website but they refuse to give PWAs access to essential features such as push notifications.

Yes. And that is okay for the vast majority of consumers as well.

Are there compelling PWAs on other platforms that are killer apps? Somehow Apple always gets called out here (despite being one of the first to support PWAs and to enable advanced functionality), yet the average Android user I suspect has approximately zero PWAs installed. The average Windows user - Zero. The average Linux user - Zero.

Make some killer PWAs that people cry for and the user base will demand it. But as is it seems to be mostly dreaming and imagination that Apple is the boogieman.

HEY could have been a PWA. The UI is just web after all.

Edit:

Also, an argument could be made that because Apple doesn't really want PWAs on iOS nobody is investing in make a good one for mobile.

I would also add ChromeOS to this list. It has a decent install base and should be a killer platform for PWAs. Haven't seen anything notable here though either.

If App Clips launch instantly enough, this could be the beginning of a sort of "parallel Web" that delivers native applications instead of HTML. Which, of course, has both benefits and drawbacks. But it's an interesting idea.

What are people's thoughts on this compared to Google Play Instant? It seems quite similar to me on first glance, but the special QR codes seem like a good idea for making them more appealing to advertise/try.

It's Google so they won't acknowledge that Google did it first. Will post comments on how they use Firefox and DDG.

Does it matter who did it first? Why would Apple mention or acknowledge this in developer documentation or, really anywhere else?

It's not like it's a big secret they are trying to hold or a fraud they are perpetuating. Why is there anything wrong with not advertising it?

I am talking about people on HN and not Apple.

Ah, well, you were responding to a post that acknowledges Google Instant Play, so maybe not a great spot to claim HN people won't acknowledge Instant Play.

Just look at the other comments.

There are a bunch of comments talking about Google Instant Play, and none denying it came first that I can see.

i don't why you are downvoted. There was barely any discussion on Instant apps. Its not the first time i have noticed something like this. But for a tech related site you would have thought there was more discussion rather then down voting.

Any pro Google comment is downvoted.

Two big differentiators IMO are the NFC tags to launch the App Clip and the deep integration into Apple Maps. Fortunately, I don't think either are particularly proprietary (just well thought-out scenarios), so perhaps this will lead to an uptake of Instant Apps as well.

The biggest and the most interesting difference in my opinion is how Apple thinks completely different about useful and practical use-cases for this feature.

You can find Google's introduction video here: https://developer.android.com/topic/google-play-instant

Just by comparing introduction videos you will see how their visions are different about this feature.

And Apple is going to push for those use-cases. And the good news is that Android has a similar feature. So it makes it easier to justify the effort and investment for companies to build that for users.

If you use a standard QR code, you can link to a web URL which does device based redirection to either the Apple app clip or the Google instant app, so basically anyone with a smart phone can use it. You could even have a mobile web fallback if you’re not on a supported device. If you use this Apple code thing, you’re cutting off the majority of your potential market (outside of the bay area bubble, android phones are used by the majority of people). I really don’t understand why anyone would use a proprietary code that only works on iPhones (and only on the latest version of the operating system at that).

And even the argument of “iPhone users spend more money and are more valuable to developers“ misses the point: these are supposed to be deployed on things in the real world, you want any person who sees it to be able to use/buy it.

To the extent that all of the app clip functionality seems to work equally well via QR code, using an Apple proprietary code really only adds friction to android users, it doesn’t decrease friction to iOS users. There’s no reason to use it that I can see. Of course it’s still early days, maybe Apple has some trick up its sleeve we haven’t seen yet.

> outside of the bay area bubble, android phones are used by the majority of people

It really depends on your market. If you're a parking garage in the US, about 60% of your customers are using iPhones (assuming your customer base is a perfect sample of the US at large, which is also not true). I can only think of a handful of instances in which a business type in the US would have a majority of Android users.

This has a 10MB limit for app size, while Google Instant Apps are 4MB. It will be interesting to see whether that makes developing for it meaningfully easier.

Google has since upped that limitation to 15MB.

Thanks!

One overlooked feature of this feature is the Sign in with Apple. You can use the App Clip to make a purchase and at the same time you give the vendor an anonymous email address which they can use to contact you with more information about their service. If you don't want any information, you can cancel that anonymous address.

I don't see how this can be done in a web app.

There is Sign in with Apple on the web, too.

Aside: when did Apple start putting out polished PR pages like this to "market" features to developers? I feel like this year is the first time I'm seeing them.

There definitely wasn't anything like this push for when Core Data or Ubiquity came along, even though they both would have greatly benefited from it. The only pages for individual features I recall pure consumer-focused "explainers" of the benefits+implications of things like Gatekeeper, iCloud, or Time Machine.

Is this just because this year's WWDC is online? Were they doing this sort of "hey, pay attention, this exists now, you should try building with it" PR in person before?

Apple probably knows that developers aren't the ones making the decisions on whether to implement app clips or not, product managers or the developers clients are.

They've been doing it for a couple of years. Remember when Swift was launched?

This was probably the only part of the WWDC keynote that left a sour taste in my mouth.

It’s the opposite of what I want.

On the other hand, for the companies that insist on apps, I guess it’s an improvement. Kind of.

So what google have done for the web with AMP, apple is doing to apps with clips?

I feel like this could be achieved with better HTML5 support from the iPhone and the promotion of light PWA instead.

As said elsewhere in this thread, Google already has a direct analog with Google Play Instant Apps.

Although I also wish Apple would put more than the bare minimum of support behind PWAs, from their perspective App Clips still have to go through the App Store vetting process, and therefore are (ostensibly) a safer choice than just granting more OS-level capabilities to PWAs.

You don't need OS-level capabilities to order a pizza.

Every time I read these comments I realize that apple is going to dominate again. A PWA is not vetted! If you complain about a PWA apple cannot take it down!

In your PWA / QR code utopia, after someone sticks a few bogus QR codes on parking meters, scooters and bike rentals etc that point to their phising PWA - trust is going to be toast.

Seriously - chrome getting rid of subdomains used to trick users (wellsfargo.securedomain.com) in the browser bar also generated lots of complaints - and also helps users.

Is this just a HN thing? Screw the 1B users who can't be bothered to become experts on every weird scam / original headers review etc? Because it get's a bit tiring on literally every thing that google / apple do.

> If you complain about a PWA apple cannot take it down!

Browsers already protect people against malicious sites.

You never saw Chrome warn you about it?

I don't think you realize how easy it is to setup a new website. The apple store doesn't have a lot of friction to sign up as a developer and get an app approved, but it has some. Websites are far far easier / quicker etc, and despite browser warnings phishing attacks continue to be very successful. This includes lots of creative options such as windows.net domains using azure cloud compute, cloudfront and CDN domains to host, content coming from places like dropbox, google sites etc.

We actually already know browser warnings are not enough because there continue to be incredible attack volumes in this area with malicious websites as landing pages.

ClickJacking target?

I would have expected the App Clip UI to have better integration with OS or Safari browser chrome, so that it wouldn't be possible to spoof from a web page.

Since it floats entirely within content, it seems like you could make a click jacking attack from a Safari experience.

Just one screenshot, maybe this is mitigated somehow...

The app clips still have to go through app review and the user is asked for consent before it is downloaded and launched. You also have to create them as part of a full app in the App Store (although for the restaurant ordering scenario, GrubHub or whoever would make an app clip for the small restaurant that didn't have a presence on the App Store).

Right. This would be simulating an app clip via HTML5 to trick a user into thinking they are using a safe app clip, but actually it is just a web page.

So is this exactly like Google Play Instant Apps?

https://developer.android.com/topic/google-play-instant

Hopefully similar, but better.

Just like Apple didn't invent MP3 players, but it did invent the iPod.

Have you seen it being used in the wild already?

IME, Instant Apps are currently aimed at more of a "try our app" scenario, so I've never really seen them promoted in the wild, only through links I've tapped. I don't think there's much that would need to change to enable the types of scenarios Apple has been promoting.

Instant Apps have been around 4 years now (just a guess) and I've only encountered them twice. When going to a Vimeo link or a CBC link.

CBC news has an instant app.

It looks like this is a new way to get remote code execution on a locked iPhone:

> NFC Tags: Users can tap their iPhone on NFC tags that you place at specific locations to launch an app clip, even from the lock screen.

I assume you would have to still get your app through the App Store review, but once you get past that you "just" need a sandbox escape or a privilege escalation bug to own the device. I suspect this feature will be taken advantage of by forensics software.

Yes, Android has had it for years.

The difference is that Apple will actually ship it, it will work and provide benefit.

Sorry, I didn't follow the launch. Does anyone know whether App Clips can consume/produce audio? I'm working on a musical app -- is there a way for us to "demo" our app in App Clip format, considering that it uses the mic + speaker? Thanks!

Supposedly App Clips can use every framework available to a normal app, except for HealthKit, which they explicitly prohibited. They did mention that App Clips can activate the camera, so I'd guess you can at least ask for microphone permissions.

That’s very encouraging, thank you!

I really think this is revolutionary. With Sign-In with Apple and Apple Pay, it's going to make real world digital commerce much more streamlined with Apple mediating as a guarantor for both sides. Like WeChat but unlike WeChat because privacy is respected.

Looks like this could give Apple a bit of a head start with fleshing out some of their AR app offerings out in the real world. I imagine these will translate quite nicely into rOS / StarBoard, which gives Apple a slew of apps to use on day one.

May be I am old. Even though this is so different, I have the same feeling of sidekick in the DOS world ... do not know why.

I am actually excited to see this in the wild.

I wonder how well it would work when cell reception is very bad (indoors or 3G)

Apple has a patent on context sensitive app installs/appearances. Come acrosa it some years ago.

We have been using these micro-apps in China since almost four years ago...

I wonder how much of a potential there is for abuse with this system, one thing I thought of during the keynote was:

1. Someone sticks a malicious NFC tag on one of those rental scooters that opens a malicious App Clip

2. The App Clip seems like it could be for the rental service

3. App Clip maliciously takes your money and runs.

Wonder how much something like that could become a problem or if Apple would be good enough about preventing/stopping it.

That's a bloody clever trick :)

I assume Apple is hoping to rely on its curated app store to protect against that, but that is more of a social attack, so maybe we'll see it happen or something similar.

The "easy" fix is to make it obvious/hard to hide what the _real_ app clip should look like in-situ.

The defense here is presumably the same as against a "Starbux" app that faked orders to Starbucks and kept the money: it would either not make it past App Review and into the store or as soon as someone was scammed and complained, it would be taken down.

It sounds like this sort of attack would not be widespread (because Apple would revoke the app rather quickly) but be great for spearphishing or high-value targets.

Couldn't this already be done with QR codes linking to a malicious website?

1. App clip needs to be registered with Apple 2. The web domain needs to link the App clip (Apple App Site Association file I'd presume).

So this wouldn't work straight off as you describe. The NFC payload is just a url this url is sent back to Apple servers to load the App clip.

What could work is someone uses a legit App clip and hijacks the corresponding web site and places a malicious payload and tricks the App clip to load the malicious payload and tricks the user to tap on NFC / QR code and exploits App clip. Even then the last line of defense - sandbox needs to be circumvented.

Nevertheless, this is definitely a new attack vector and there will be exploits from NSAs.

Reply on news.ycombinator.com