These shenanigans make me wonder why they don't just focus on making HTML5 apps a better experience. If they provided better widgets (e.g. including swipe gestures, which Angular/Polymer/MDL don't) and access to native hardware we'd be set.
HTML5 is just 100X easier and nicer to program with than that abomination of Android Studio followed by aligning, keysigning, and other steps.
The HTML5 hello world is
<html><body>Hello World</body></html>
The native hello world is no less than 74 files of garbage, Gradle configurations, and other nonsense.
You're free to make web pages if you like but despite your complaints, you yourself admit that its not a better experience and its not for lack of effort.
Because there's no clear way to get a cut from payments for web apps. Nobody will pay 30% to Apple if there's a way to avoid doing that and web app would be a way to do so.
If all you want to do is deviate from standards on purpose, just change
<html>
to
<apple_ml>
and base64 encode the .html file (for no reason) and call the resulting file .iapp. Done. Standards broken. Proprietary status achieved with minimal effort. Change ".css" to ".bss" if you want to go the extra mile.
and leave everything else as-is? Sounds like a win-win for both developers and biz dev.
This (or something like it?) has been available for ages, but the only time I've ever actually encountered it in the wild is with links to a JIRA project.
We have this instant app feature in our roadmap for more than 2 years. Every time we start with it, we run into the endless list of difficulties to get it to work. Max size, different modules, shares resources etc. It's hell on earth for most devs. That's why you see almost no apps having it. The idea is nice from a Google perspective. I would rather just add a link to each app in the playstore which goes to the app website. Up to the developer to create a web version of it. But of course this gives zero control to goole
A local news site uses it, however as that's in a (distant) second language for me, and I discovered their app doesn't let me select to copy-paste words into a translator, it wasn't useful. Probably just an issue with their app implementation however.
I have an app written in Swift and weights between 8-20Mb(depending on device and iOS version), which is not too far of from a typical website these days and the startup times are phenomenal(between 250-500ms, depending on the devıce).
Writing in Swift is a delight and this is the feature I was dreaming about because having the user to install the App is not easy these days(100 impressions on Appstore Search would get me about 8 installs) however the people who install it are quite happy according to the feedback.
I would imagine that the experience is similar to Apple's AR experience on Safari, which I feel can be improved but much nicer than opening the Appstore still. Let's hope that it's not too limited and can be possible to give a good feel to the user about the App's full functionality.
The article talks about letting the dev to pick which part of the App would be presented but I suspect that the actual implementation would be similar to making an App Extensions - basically creating a separate mini-app that shares the codebase and the resources.
It's hard to imagine, but some DOS apps had <100ms startup time on a 486 while coming full-featured on a 1.44MB floppy disk.
I agree that your app is small and fast compared to what others are putting out there, but compared to what software engineering could do if people cared, this is still bloated and slow.
And it had 2 squares on the screen with 10 pixel letters inside them saying 'Proceed y/n'?
What kind of a comparison is that? People do care, it's just they care about ease of use (not putting strain on your sanity) over some imperceptible startup time difference or space difference on hard drives that get cheaper every day.
I bet I can get this number lower with some lazy loading but what for? The app is loaded by the time the springboard animation ends, the user interaction isn't likely to start before that.
It's a new App that I try to iterate quickly, so I prefer to keep away of added complexity that optimizations would bring. If it feels quick enough on the lowest end device that I support(which is iPhone 6s because of iOS13) it's alright. The mobile devices are very powerful these days.
When you are used to desktop apps coming up and being useable literally in the next frame of you launching them, any interaction with mobile decices and webbpages with loading times everywhere is absolutely terrible. Makes me remember all the game consoles which would have loading time ms everywhere - it was terrible and frustrating when you were used to PCs
A large part of the bloat is from graphics assets. The icon for most apps is many times larger than these old programs and you can’t do much about that. It’s one thing people don’t realize that happens when you get these hidpi screens.
With Objective-C apps, it used to be even better, in startup and in app size. I think you can still get similar app size if you make a pure Obj-C app today.
The nature of swift itself, similar to C++, makes it create bigger binaries compared to equivalent Objective-C code. So even with no runtime included, they will still be bigger on average.
What's the status of Objective C language today? Is it fully supported forever or is it in legacy status waiting for its support to be dropped in the future?
It will be fully supported probably forever since Apple wrote a ton of their own systems in it and it has perfect integration with C and C++. The language is basically done at this point, any new features will probably be aimed at language interop.
Thanks. I'm not a vivid iOS developer, but I'm writing some apps sometimes. Swift is so fast moving target that I don't want to pursue it, while Objective C is a language that I know and actually like. It's like C vs C++, I learned C++ 15 years ago, but it's completely different since then, so my knowledge is basically useless without solid investments, while C is almost the same as it was 30 years ago.
Before Swift become a thing I look at Objective-C but it was so irritating that I stuck with JavaScript. It's probably faster but what difference it would make to open the app faster than what the user can perceive? I can use static images to give the impression that the app is already running, which is recommended by Apple anyway since the user won't be able to react before the app is fully loaded anyway.
The unnecessarily large apps probably use cross-platform tools that ship their runtime with each installation, losing out on Apple's optimizations or they have multiple ad tracking or 3rd party UI libraries.
I am not an expert in mobile dev by any means since I switched from web to native mobile development barely a year ago but when I was still resisting to learn the native way of doing things I was exploring the cross-platform solutions and libraries to "take advantage of my current skills", anything that goes beyond the demo todo list app quickly escalated in resource consumption and development complexity.
With these cross-platform tools, the moment you try to do something a little bit differently than everybody else, you find yourself stitching multiple 3rd party libraries together and these libraries add up to the binary size and loading times.
> With these cross-platform tools, the moment you try to do something a little bit differently than everybody else, you find yourself stitching multiple 3rd party libraries together and these libraries add up to the binary size and loading times.
This.
I have tons of native iOS experience.
Started with react native a little over a year ago and was shocked at how difficult some things are. Easy things are easier. Hard things are harder.
I think adding the Facebook SDK added something like 40-120MB to my app if memory serves me correct. One more reason I always use the mobile web version in a WebView every time I can get away with it. It has all of these dependencies like Bolts and what not. All to display 2-3 screens worth of login.
Hmm it might be worth you checking out capacitor, I've shipped a couple of full featured fairly complex apps under 5mb that use the same codebase for iOS and android.
I steered clear of ionic and angular developing my own framework and the apps had less than 1mb of assets bundled with them.
The reason why this is needed at all is because a todo list regularly needs 20 MB updates.
The problem is that there is no incentive for developers to keep their apps small. And since Apple makes money from selling larger phones, they also have an incentive to tolerate bloat. And lastly, your provider will be happy to charge you astronomical fees for downloading that critical update over mobile data.
There's nobody making money from small apps but 2 of 3 parties can monetize bloat. So bloated apps it is!
The name Clips and the QR scanning suggests to me that this will be used for advertisements, like those AR overlays.
Android has Instant Apps. Not sure how others feel but I hate it. Compared to a website it's slower to load, harder to share, and outside of my normal flow.
I guess it would be cool for a demo but I dunno. Also iOS apps are so large this won't be practical at all on cellular data.
>Also iOS apps are so large this won't be practical at all on cellular data.
They don't have to be. For example Tweetbot, which is a fully functional app, is only about 7MB. It's not hard to imagine that a single screen of an iOS app specifically optimized for space could be only a fraction as large – considerably smaller than the average site these days (10MB+).
Wouldn’t it be more surprising if Apple wasn’t working on something like this? Even if it is true, basically it sounds like someone leaked out a test build of something. They’re probably prototypes for all kinds of crazy things, some good some bad, just like everywhere.
This looks similar to wechat mini programs. They are instants apps availible from within the chat app. They are very easy to share. They are a real game changer. E. G you go to a restaurant scan a qr code and order and pay through the mini program.
Sounds like a horrible idea. Why on earth would I want the act of scanning a QR code to start downloading & executing random code. Heck native code too since they say it's an app.
Well that what you are doing when you scan a QR code a put the URL in your browser.
You download random code that the server send to you, and execute it.
I doubt in practice it would be completely random. Most likely it would still need to be reviewed/verified by the App Store review board, and most likely it would still require asking for permissions just like any other app.
This could be a real game changer. I think it might be part of the drive into AR
Instagram and snapchat have ways to launch interactive experiences from a code and I’ve always thought Apple are missing a trick there.
One of the biggest hurdles getting clients to make apps now is “no one downloads apps anymore” so this could make a huge difference and make more frivolous interactive experience work in apps again.
MIUI has had this for a couple of years already. Leverages the Android feature for Google Play Instant as @esmi mentioned. I dont know how it works but effect appears to be a wrapper of sorts is setup for the app so the app itself does not get installed. Not all apps support this mode for reasons with which i am not familiar.
Every app i've seen use this uses it to implement a "microsite". for eg nytimes made an instant app for the crossword puzzle on android...
except if i'm into crossword puzzles i'll download the app anyways,why the hell would i download the instant app everytime unless it was part of my "flow" ie read the new york times paper and then the crossword is sent to my phone automatically or something?
except i'd be reading the paper on my phone as well?
the usecase for these kinds of things is so muddled and unclear i don't understand the point...
I wonder if a phone OS will move to Google Stadia-esque offer: your device is just a remote viewer, everything including rendering the UI happens on their backend (Marketing has a field day touting Cloud-features), and is streamed to your device.
Of course it'll be limited to places with high speed cellular Internet, but hey 15 years ago no one thought we'd be able to stream 3D games over the Internet..
This is common in Windows environments and is called app streaming / virtualization there. It’s been included in Enterprise editions of Windows feature called AppV. This must be something similar. App Store sales more profitable than iphone/iPad device flash size?
Considering that nowadays the average website is clocking in at dozens of megabytes of obfuscated JS and/or WebAssembly, I'm looking forward to lightweight and snappy native applets as an iOS alternative. Hopefully Apple enacts a hard limit on size.
The web is the biggest threat they face to their App Store.
They see the writing on the wall with technologies like wasm blossoming, and with web APIs beginning to open up possibilities for “native”-quality apps.
So they’re interested in anything that can reduce the friction necessary to get into native iOS apps.
Seems like a terminal, storing the content in the cloud like a container where the app lives up there instead of in your localhost, but still uses the native interface APIs.
Hope the security around this is air tight. Otherwise this will definitely be a new attack vector hackers will be using to get malicious binaries running on your phone.
This is going to be another Apple success story along the lines of: Yes, others have had this for years in theory, but nobody actually ever used it. Apple enter the market super late but instantly capture it fully because they're the only ones not monumentally sabotaging themselves.
> this new API, we can say that it allows developers to offer interactive and dynamic content from their apps even if you haven’t installed them
Also formerly known as Web Applications but now made by Apple with the added features of less control from the developers, a 30% mandatory fee if you accept any payments of any kind and locked to just one platform.
Nice snark, however web apps are still possible, and Android has a very similar feature (Instant - enabled by slices). Did you provide similar feedback when that was announced?
> Did you provide similar feedback when that was announced?
I did not, as I'm a lot more bored at this point in time and also have a lot of more free time.
But I do feel the same about both of the platforms movement towards "instant apps" that could have been equally solved by making web apps work better on respective platforms, instead of trying to solve the same problem again.
> But I do feel the same about both of the platforms movement towards "instant apps" that could have been equally solved by making web apps work better on respective platforms, instead of trying to solve the same problem again.
The web ecosystem has been trying to solve this for almost a decade now and has made relatively little progress. There's no reason to believe Apple could suddenly solve it in a few months if they just cared a little harder.
Web components & shadow dom are approaching 10 years old and still have issues with framework & browser support. asm.js is 7 years old, yet the ideas birthed from it are still struggling. Effective parallelism is still largely nonexistent. RAM & CPU/GPU efficiency remain a bad joke, made worse by the entire world now running on battery power.
A huge number of people are working on making web apps more viable, including people at Apple. It's not from a lack of trying at this point. The foundations are just all terrible & wrong for being an app platform. That's never what it was built or designed to be, and retrofitting that without breaking compatibility is really really difficult. If it turns out the incremental delivery benefits of the web can be retrofitted to an existing app platform more easily than the web can be retrofitted to be an app platform then... well, why not? The cross-platform-ish nature of the web was (and is) a great dream, but why can't that dream be realized by SwiftUI instead? Or Flutter? Or whatever? Why must it be web alone that gets to be that thing?
> There's no reason to believe Apple could suddenly solve it in a few months if they just cared a little harder.
No, they really could just solve it. Progressive web apps are so close to being useful. Apple just refuses to make them user-friendly to install. Just look at android for what's possible https://web.dev/progressive-web-apps/
> Progressive web apps are so close to being useful
PWAs have been pushed since 2015. 5 years of perpetually being "so close to being useful." And that's despite Google's heavy promotion of them, including building an entire OS around them.
I think it's worth separating web components and shadow dom from asm.js. The former are trying to improve the browser and the later are taking browser open philosophy everywhere. Browsers have full support for WebAssembly and keep working on optimizations. It's also taking off outside the browser too (WASI, Cloudflare, etc). If WebAssembly succeeds it's precisely because innovations in the browser did not, and we had to break it open.
Web apps have always sucked and always will suck. With decades of development and thousands of frameworks, it still sucks.
Instant apps take the one advantage web apps have (you don't have to install them) and brings that to the native platform. I think that makes a ton of sense, vs "just fixing" something that people have been trying to fix for decades.
How often do you go to uber.com to call an uber? If you want to build a product people actually want to use, make it native.
I'm using a ton of apps that have Web and native options and in most cases I prefer the Web version. I'm sure others feel differently and that's fine.
But you're forgetting two major advantages of Web apps: They are cross platform und neither users nor publishers need any permissions from some oligopolist middleman.
Cross platform web apps are a myth. You have to test a comparability matrix of all the major browsers on all the major platforms because they are all different in subtle ways that actually matter when making complicated apps.
Native cross platform toolkits like Qt are no more work but provide a much better user experience.
And I agree that the current state of the mobile platform monopolies is a shame. If you care about Android, I encourage you to publish to Fdroid.
Instant Apps on Android are opt-in (provided by a popup the first time you open an enabled link), so I can choose to use web apps if I prefer. I think the important open question is whether Apple will take a similar approach or if a Clips-enabled app will always take priority over a web one.
Perfectly valid question - I too hope for an option to keep this capability disabled or available on a per-use basis rather than a complete replacement for the existing QR URL launcher.
"with the added features of less control from the developers"
Given that this is an additional option for developers, this is pretty tenuous logic. You seem to be arguing against developers having this option by claiming that it restricts their options.
"and locked to just one platform"
I'm fairly sure making one of these apps doesn't suddenly restrict every other option. You can make Android and Web Apps and J2EE (if it still exists) to your hearts content!
This is actually a convenient conversation because I just spent thirty minutes thinking about how much of an absolute piece of shit the Steam app is, courtesy of all of the elements that are a thin wrapper around a web app. And this has pretty much always been the experience: we're all just waiting for the magic web app that's going to prove everyone wrong and light the path.
Still hasn't come.
But until then, I'd rather developers actually have options, including high performance, native, platform-suitable solutions. My only knee-jerk opposition to these Instant App style solutions (the Android version, not sure what the Apple one will be called) is the thought of a big, fat binary coming down just to view what you think is a web page...and then I remember how absolutely monstrous the overwhelming majority of web apps are now. Full native apps are absolute svelte in comparison.
Pretty sure this would be enabled by an app's universal link. URLs already work with the QR code scanner today and invoke Safari. This would be under developer control. As usual, any attempt by Apple to live as an alternative to the open web is seen as an attack on it.
Well, it does have a difference. You have full access to all native capabilities on the platform. That isn't true from a webapp. I'm not casting judgment on which is better but it is different. Actually, I wish this feature was a combination of install and run with parameter in a single step, controlled by the OS.
True, but that's only true because of Apple wants it to be like that, not because there is some physical impossibility to integrate native platform APIs in the browsers.
You can already code "native" iOS apps in React Native if you're so inclined. I can't really see a difference between devs coding against native iOS APIs in the browser that I end up having to download in order to use offline vs downloading apps coded against iOS API's downloaded natively from the app store.
I upvoted you because, to me, you're pointing out what should be fairly obvious to everyone. It seems clear to me that big tech companies have been pushing for ways to usurp the open web.
I disagree with your assessment. Web Applications involve running JS downloaded from a remote source. If this is closer to slices, as the article says (did you read it? assuming yes, as this is HN and not reddit), then it is very different. Web applications are not native UI, and often have far worse experience and clunky usage of things like cameras, peripherals, system audio, etc. Slices would ostensibly be native code bundles, verified and tested by Apple. Moving away from web-ish experiences to native ones is a huge win in my book.
PS/opinion/fluff: There is also the implementation detail of language. Swift/ObjC is significantly superior to JS.
> Web Applications involve running JS downloaded from a remote source
Any "instant apps" like this is gonna involve running code from remote sources. Then if the code is JS or Swift doesn't really matter.
> Web applications are not native UI
That's true. But that's up to the company deciding over the operating system and the browser in the end. Apple could have easily expose ways for web developers to write native UIs in HTML, CSS and JS. In fact, browsers used to be "user agents" where the user (and effectively the operating system, but user had final say) decided the styling of the content, but then website CSS became a thing and websites starting getting more control and wanted unique looks instead. Judging by the usage of the web, it seemed to have worked out pretty fine.
> Moving away from web-ish experiences to native ones is a huge win in my book.
Native in this case means running on one platform. I would much rather focus on making something that works for a bigger part of the world, meaning it doesn't exclusively run on Apple hardware but Windows and Linux as well. The browsers are one way of achieving this. Would be great if everyone (mainly Apple, Microsoft and Google) could align themselves behind one platform and work together. But I guess I've been in isolation long enough to start dreaming impossible dreams.
But considering your PS/opinion/fluff, I'm wasting my time discussing with you...
Hope you're having a good time anyways and take care!
> That's true. But that's up to the company deciding over the operating system and the browser in the end.
The OS is far more powerful, and allows for deeper integration and writing in far faster languages. The browser abstracts away the machine. Most JS writers today have no idea or understanding of the actual computer they are writing against. It's a sandbox for them, and it's the reason apps today bloat to hundreds of megabytes and burn CPU to do the most mundane thing. Less distance from the metal is better in my book.
> Native in this case means running on one platform. I would much rather focus on making something that works for a bigger part of the world.
Feels like a strawman / bad faith argument. As a user, I'd rather use one fast app on my device, I don't care if some guy on another platform can use this product. As an engineer, I want happy users, and if that means writing X clients, so be it.
What is native? On Android the native Java UI kit is slow and not native.
You need a lot of fancy work to get fast c UI libs working on the 1000 different android devices. Goodluck with that. Browsers are probably the most optimized virtual UI machines out there. Sure not native, but I would argue that an integrated webview with proper css3 is much better optimized that using the android component framework or native draw operations. On ios things are slightly different, but also there the standard UI toolkit is a freaking nightmare. Creating general purpose UIs in a language like css feels so much better than most if not all UI toolkits out there.
>Would be great if everyone (mainly Apple, Microsoft and Google) could align themselves behind one platform and work together.
So you want mediocre, resource hog, lowest-commmon-denominator apps? Because that's how you get mediocre, resource hog, lowest-commmon-denominator apps.
> Apple could have easily expose ways for web developers to write native UIs in HTML, CSS and JS.
Easily?
As as far as running on one platform, I like native because my iPhone X Pro has a heck of a lot more capabilities than some generic back alley Shenzhen Android device. And multi platform necessarily requires developing for the lowest common denominator device.
And JavaScript isn’t the best language for everything, let’s stop pretending it is.
Yes from Amazon and other trusted places. I’ve done in app purchases for games (to remove ads) for a lot of companies. I wouldn’t do it if they had their own payments.
Apple apps can only be developed on Apple computers and if you pay a fee to Apple for the privilege. And they own the app store. There's lock in and then there's complete vertical integration.
