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.
...of course this requires developers to use it, but then so does App Clips.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
See real estate apps or corporate travel apps for instance. A majority seem to be the same few practically unusable apps re-skinned.
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.
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’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.
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.
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.
(this post represents my opinion only, and does not speak for my employer, my cat, or the flying spaghetti monster)
Because Apple is known to kick apps out if they don't like them?
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.
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.
It seemed like a really cool idea, shame it never took off.
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.
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.
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.
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.
Right now however it seems to primarily be marketed to mobile game developers.
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
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.
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.
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.
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.
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.
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.
I've heard that SVG has been supported for a while, but I have not used them (yet).
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.
So, a native app?
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.
...that's... what this is?
Got any stats for that? I was quickly able to find  and  which state that web page sizes are 1.5mb (median), 2mb (mean) and the average is about 3mb.
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?
Let these companies build the integrations and find creative use cases around them!
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.
But can I ask for credit card information and not use "Apple Pay". The "instead" is super weird there.
Also, why not just PWA ?
"Apple Pay" doesn't mean Apple Card. You can have a bunch of different credit cards loaded into Apple Pay.
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.
You could make it easy to do ApplePay, and also have a "enter CC in the main app" approach.
You may be thinking of the fees associated with in-app-purchases?
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.
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.
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.
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.
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.
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.
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 don't see how this can be done in a web app.
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?
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.
I feel like this could be achieved with better HTML5 support from the iPhone and the promotion of light PWA instead.
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.
Browsers already protect people against malicious sites.
You never saw Chrome warn you about it?
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.
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.
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...
Just like Apple didn't invent MP3 players, but it did invent the iPod.
> 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.
The difference is that Apple will actually ship it, it will work and provide benefit.
I wonder how well it would work when cell reception is very bad (indoors or 3G)
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.
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.
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.