You can't even go to the website in your browser if you don't have internet. Local storage is nice, but by that point the problem has already occurred.
Apparently I'm missing something. How do you go to the website to even load the code that talks to the local storage? (Also that last link says it's been deprecated and is being removed).
Absolutely. I don't want to be forced to download another shitty app for every single website I use on my phone once or twice a month. Looking at you, SoundCloud.
Like facebook messenger. It worked great, and then they took it away, and then "request desktop site" still worked fine on larger phones, but I think they've recently done some weird WebGL things that make it impossible to type in any of their input fields without a proper desktop browser.
"A Hybrid version of an app will never be as fast as a native version of the same app, but it doesn’t matter as long as the Hybrid version is fast enough. Put simply, if your users never complain about the performance of your app then it is fast enough."
Battery usage can still be a problem even if the app appears to run smoothly.
In addition, just because nobody is complaining doesn't mean you aren't wasting their time.
"Well, let's say you can shave 10 seconds off of the boot time. Multiply that by five million users and thats 50 million seconds, every single day. Over a year, that's probably dozens of lifetimes. So if you make it boot ten seconds faster, you've saved a dozen lives. That's really worth it, don't you think?"
I suppose the assumption there is that me must stay perfectly still and stare at our phones during this time? My toaster takes a while to toast break. My coffee maker takes a while to brew coffee. I don't really consider that wasted time, because it doesn't require anything of me, and I'm free to do something else.
Which explains why nobody cares about hold times, shipping speeds for purchases, or when other people are late. You can just make toast while you wait.
More power to you, but I find the short pauses in apps the worst. If some function is going to take time to run and I expect that, absolutely, I can walk away and come back to it. I do this frequently. But these are not the sorts you generally see on phones - you get terrible 7-10 second pauses as something slow launches, talks to a slow server, thinks weirdly hard about something because of a slow loop, whatever.
Especially when unexpected, 7 seconds is insufficient to task-switch, so yes, you end up staring at your phone.
The example wasn't perfect, but often I'm using my phone when moving between place to place. I don't stop walking to to wait for an app to load. You also don't need to stop thinking just because you are waiting for something.
The idea I'm really calling into question is "So if you make it boot ten seconds faster, you've saved a dozen lives." Waiting for your phone to do something isn't like being in a coma, where the time is irretrievably lost and provided no benefit (beyond what it might have allowed recovery wise), nor is it like sleep, where we spend a significant portion of our lives doing it and we can't do anything else during that period (even if that period itself is beneficial).
Delays are annoying. Making delays shorter is good. Saying shortening delays saves lives worth of time is problematic. Even the original commenter acknowledged that was probably reaching (it wasn't his quote).
I'm quite digging this unique take on the matter, yet for all its charms I'll remain firmly in the camp that: "nobody-complains is probably putting the bar at the appropriately realistic level for gimmicky indie-hackery side-products" (photo battles?! =)
Honestly something as simple as photo battles should be wicked fast. It's doing so little (calculation wise, I would assume) that it should run it about the speed of your Internet connection fetching images.
> if your users never complain about the performance
This is a problem. Some user not even know what a fast app look like, neither have the hardware (hello old PC, hello cheap Android) or blame themselves for any problem or just assume "is supposed to be like this".
Take for example the Android emulator (and in this case, using developers). In the moment I launch it, the FIRST TIME, i instantly look for a alternative (was impossible slow). However, how many developers stick to it, and have even less powerful machines than mine?
Or using something else: How many people think that miss keys in the keyboard is his fault and not a problem with cheap rubber domes? And how many know exist mechanical or have used a old quality keyboard?
Ignorance of the users is NOT their problem. Is OURS.
AS3/Flash was an amazing language + ide. It included a simple syntax, layers, a great system of events and callbacks, animations built in, timelines, vector graphics, etc. I and other AS3 devs (2011) could write code x10 faster than anyone in obj-c. The concept of AS3/swfs running on an iOS store could mean the end of control of the apple app store and the break down of the obj-c community.
Apple completely fucked over AS3/Flash. Adobe launched multiple attempts to work with apple to build out a system to launch swf files on a iOS device. Apple could have helped. Adobe should have played hardball and yanked photoshop [+studios] from the osX.
> Apple completely fucked over AS3/Flash. Adobe launched multiple attempts to work with apple to build out a system to launch swf files on a iOS device. Apple could have helped.
The problem rather is in the Apple users that accepted this behaviour from "their" company.
Blackberry designed their whole OS and app development ecosystem around Flash / AIR. It performed surprisingly well, but obviously their devices was not successful in the marketplace.
Android was hit or miss depending upon the specs of the device.
Sure, but JavaScript is an open standard and you can tune your implementation at will.
Compare that to being at the mercy of a company like Adobe that bundles at least 3 different JavaScript interpreters, a full blown WebKit and who knows what else to Photoshop. All while having a custom made cross platform UI layer across all of their apps.
That's simply bad app or library code. Any website can take up 100% of a cpu thread. If all threads are used then even the greatest workstation will slow down.
This is quite true. I had nothing but disdain for Flash back in the early noughties because, almost universally, everything I encountered that was built with it was terrible, especially those CPU core swallowing ads.
Nowadays of course we have CPU core swallowing and battery draining JavaScript ads, along with massive JavaScript bloat in general. For the heck of it I just went and had a look at one of my own pages, which runs an HTML5/JS/CSS game, and includes Adsense. It downloaded 633KB of JavaScript. By today's woeful standards that's not even particularly bad. To break it down a bit though, 52KB of it is scripts I use directly, of which 47KB is required for the game. The other ~5KB is FontAwesome, which I use for icons on the menu buttons. The other 581K? Well, Adsense itself is also fairly small (about 35K for two scripts), which leaves the rest - the vast majority - which is loaded by the ads themselves.
Like you, I've come to realise that it wasn't the tool/platform, but the people building for it. Clearly the best developers are not building ads. It feels like there should be some scope for disruption here.
I think browsers could throttle scripts loaded from cross origins. That may allow the main website to load faster, but then I guess from the content owners point of view the most important thing is getting the ad code loaded and registering hits :(
That's true, I remember when Adobe Air first came out for mobile devices and I was completely heartbroken at my game which ran 30 fps on desktop choking at 4fps on the iPhone.
I don't know if this is still the case (haven't cared much about the mobile market for a few years), but what the Android and Web markets were missing that made iOS a necessary target was: users willing to pay money for apps. I don't recall the exact percentages, but many mobile app companies were reporting that iOS users made up 20% of their users and 80% of their revenue. Something like that.
I seem to recall flash being power-hungry, slow, and a security nightmare. All of those things would be bad for iOS.
Remember how in the early days it was a "big deal" that android phones supported flash but iOS didn't? Tech people used to think that was important, and it netted android some sales, but in the end everyone had to admit that it was kind of a bad idea.
However, as a platform the player was lean and optimized. A lot of people wrote horribly inefficient things with it, which gave it a reputation for being power hungry and slow.
There were additional performance issues on Mac desktops where certain APIs for video playback were blocked.
As an end user, I can't say I'm particularly sorry about how this turned out. Flash was a security nightmare, and devs that continued to use it in light of that helped an ecosystem that put their customers at risk. Ease of development should not be the only constraint.
Flash the development environment was pretty great, and nothing comes close to it today. The closest I can think of in terms of ease of picking it up for artists/designers/etc is Unity, but it really is built for 3D first.
Adobe screwed over Flash and the number of major vulnerabilities discovered in the decade since iOS 1.0 has proven this to be absolutely the right decision. Apple has the responsibility and the right to put their user's security above and beyond the needs of a minority of developers.
Also your point about AS3 versus Objective-C is hilariously stupid. Anyone experienced in a platform is going to find development quicker than someone who isn't. I would be 10000x faster building an app with Objective-C because guess what I don't even know AS3.
> Also your point about AS3 versus Objective-C is hilariously stupid. Anyone experienced in a platform is going to find development quicker than someone who isn't. I would be 10000x faster building an app with Objective-C because guess what I don't even know AS3.
AS3 was definitely a great language to use. Good mix of OOP and functional, typed as much as you wanted it to, good tools. I wasn't really an AS3 developer (only did 2 projects with it) but I remember it very fondly.
That said, I'll never miss Flash. The web became a much better place the day it died. Maybe it could have worked better on mobile devices? I have no idea, but I'm definitely not sad that Apple said no (because that kept it out from my Android phone too)
The death of Flash was definitely bitter sweet for me. Working at an agency that mostly made Flash games/experiences from 2004-2011, there were a few years there after the final nail was put in Flash's coffin where we had to completely reset our expectations of what was possible in web based games (that run on the majority of browsers/devices). In most cases it was more time consuming and costly to build lower quality stuff.
Granted, mobile devices were never a target for Flash games, so the biggest problem was that all the sudden our clients needed content to run on a new lower power device in addition to desktop browsers. Previously our biggest problem was clients that needed things to run in old versions of IE (IE6 anyone?!). Our last couple of Flash games that we built 5+ years ago are still far more impressive (on desktops) than any HTML5 game we've since developed (and we've developed A LOT of them!). GPU access was made available for the Flash player shortly before it died. A lot can be done now with WebGL, but wide device/OS/browser support is still a problem.
We've since branched a lot more into native app development where we can continue pushing the envelope visually. Our JS games continue to feel like they have handcuffs on them and still can't compete with Flash 5-7 years ago.
Flash was awful. It was buggy as hell, resource intensive as all hell, and a huge security risk. I am glad Apple did not allow it, otherwise every iOS device would have a glaring backdoor to where the government wouldn't have to ask to decrypt iPhones.
One of the best answers here. Initially, if you watch the WWDC keynote, and if you look on how to make "apps" for iPhone Software 1.0, you'll see that Apple had a website to teach you on how to make "webclips". So iPhone app would be mobile site you pin to your springboard and that was it.
The experience was painfully slow and clunky, so by iPhone Software 2.0 they rushed a native SDK. Which you could see it was rushed because it was very lacking and buggy at first.
Why is this down voted? It's absolutely verifiable. You can watch the keynote and then go read the headlines lambasting the decision. It's why the phone launched in Summer 2007 but the App Store launched in Summer 2008.
I didn't downvote, but the comment misses the point of the article. Were web/hybrid apps the right choice in 2007? No, but that doesn't mean they can't be in 2017. The hardware is orders of magnitude faster and the software ecosystem has vastly improved.
It wasn't a great idea to start a internet-only business in the mid 90s (with some obvious exceptions), but the same isn't true today.
Apple didn't expect developers to want to develop on the iPhone so strongly. There've been interviews that said that they were going to release an SDK eventually but when there was such strong demand they had to get something out and what they got out was the web clips thing.
What I've heard is that in 1.0 they were really different bits of software many of the applications had their own implementation of UITableView... basically things were a mess. So Apple put out the Web stuff while they got everything cleaned up and standardized and documented to the standard they want to give out to third-party developers.
>> There are some major advantages to the Hybrid approach:
You get to utilize your existing JS, HTML, and CSS skillset to develop a single codebase that runs on both iOS and Android.
This is assuming you have a JS/HTML/CSS skillset.
>> Here’s some Apple BS we can’t avoid no matter what approach we use
>> Xcode
I've done some React Native development and Xcode is almost entirely avoided.
>> Provisioning Profiles
It's been a long time since I encountered issues here as it's all managed by Xcode nowadays.
>> Needing to use TestFlight for beta builds
Why is this BS? You could also use Ad-hoc distribution along with something like Fabric for small scale beta tests.
>> The app review process. Admittedly, the app review time has dropped to about 2 days on average, but when your app gets rejected 7 times like Rizer did (for legitimately silly reasons), your patience can really start wearing thin.
I've been developing on iOS since about 6 months after the App Store became a thing. I've developer dozens of apps and submitted hundreds of updates. I can count on my fingers the number of rejections I've got and there were only one or two that were 'silly' (and those were fixed through a quick appeal). Without the author listing the reasons for rejections it's hard to draw a conclusion here but complaints about rejections are usually BS.
Overall I can't help but feel this was thinly veiled clickbait to advertise the authors app.
Technically it's not illegal as in criminal, but it is a violation of the contract you're agreeing to in the form of the software license. And the macOS software license only permits running macOS on Apple hardware (it can run in a VM, but the VM host must be Apple hardware).
I understand that some of these EULAs aren't enforceable everywhere, in the form of consumer protection laws inhibiting what's basically perceived to be bullying behavior. At least in the U.S. consumer protection laws are weaker, depending on the idea that when consumers are bullied, they'll spend their money elsewhere.
In a global market, asymmetric consumer protection laws aid bully behaviors. The countries were people are safe flaunting EULAs may have higher usage rates of software with unfavorable EULAs, rather than using alternatives with a more favorable EULA.
They've always been this way. There was a short period of time with Mac clones, but there was still a license that said you could only run macOS on Apple hardware, or Apple licencee hardware.
I totally understand not liking the license, but if you click the agree button when installing the software on non-Apple hardware, you're basically lying.
If you're a company, buy a used Mac, then. They're honestly not that expensive, especially considering all of the other stuff you have to pay for as a business.
Apple doesn't write laws and someone with no contract with is not bound by their rules.
If you acquired Mac OS X legally how would this be illegal? I will admit acquiring it legally could be tricky, but that is not what we were calling illegal was it?
Breach of the terms under which the OS was licensed to you. You can acquire the software legally pretty easily: buy a box in one of their retail stores.
The (mostly-untested) theory is that clicking "I agree" on the license is a legally-binding contract between you and Apple. The Mac OSX license repeatedly says that a requirement of the use of the software is that it be used on Apple-branded hardware.
So, "illegal" based on unlicensed use of copyrighted material or based on breach of contract. At least, that's how I understand the argument.
Yes but what I got from the article was that 'you have to use Xcode and Xcode sucks/is a pain to use'. In my (limited) cross-platform dev experience you open Xcode to press 'run' so your app runs on device (and you can do this from the command line if you prefer) and to 'archive' which brings you through a wizard to upload your app. So you avoid all of the Xcode pain points.
You've got to buy the device itself? OK, makes sense. You've got to buy PC hardware, but are obligated by the software license to buy it from one particular vendor? OK, yeah, there's a business reason for it, but it's irritating because there's no technical reason.
I can easily develop iOS software without owning an Apple computer...but I can't do it legally. I'm happy I'm not in mobile dev, and this is one reason.
> I've been developing on iOS since about 6 months after the App Store became a thing. I've developer dozens of apps and submitted hundreds of updates. I can count on my fingers the number of rejections I've got and there were only one or two that were 'silly' (and those were fixed through a quick appeal).
So,you've pretty much established yourself as an expert in the ecosystem. That actually lends less credence to your counterarguments in my eyes. It's all too easy as an expert to overlook the pain points that you've become accustomed to, or did not notice as they were slowly layered up over the years. In my experience, the expert that rages against the system they use is far more likely to have valid input than the expert that apologizes for it.
That's not to say you're wrong. Just that in my eyes the likelyhood of you being right dropped as you explained how much experience you had (past a certain threshold. Amateurs often don't understand enough to accurately critique as well).
I understand your point but I think length of time developing for the platform (in this specific example) is important. Based on my experience (and I'm willing to bet if there is a large set of data available on rejections it would back me up) 7 rejections is extreme leading me to believe something is up on the authors end, not Apple's. A 5 min glance at the App Store guidelines will prevent 99% of rejections. Skill doesn't really come into avoiding rejections (besides bugs in your code of course).
The guidelines are very nuanced and reviewers are free to interpret them as they see fit. We have had an app in the store for over 2 years that jumped through hoops to avoid the 30% Apple Tax to accept a charitable donation in app. Our Apple account Rep reached out to our marketing director in the fall of last year to tell us the policy changed and that we wouldn't have to do stupid shit anymore. So we spent Nov and December developing a much improved experience. It was submitted, approved and has been available in the store since before Christmas. This week we received notification that our app violated the guidelines with regards to that specific feature and we had 2 weeks to fix it.
>It's all too easy as an expert to overlook the pain points that you've become accustomed to, or did not notice as they were slowly layered up over the years.
Same holds for the inverse: it's easy as a newb to consider everything as a pain point, even if it's a well designed procedure.
I wish we could find the Goldilocks developer to render a verdict. Someone who has just enough experience to not be used to it, but not so little that they haven't learned to use it.
Speaking as another "expert" I guess, honestly it's pretty hard to get a rejection. Almost all of mine are due to an oversight with things like the app's data and permissions, or relating to the app age rating.
Seriously if your app gets rejected that much that you'd bitch about it, it's because you're not paying attention to what you're doing and/or are up to some shady shit. It's really not difficult to avoid.
I've been rejected more than anyone on a per app basis, and your 100% right. Almost all rejections were foreseeable from reading the guidelines, in many cases I just wanted to test the boundary.
The idea that everyone a) knows Javascript/HTML and b) likes Javascript is astonishingly insular. The web is not the world, and you really shouldn't try to crowbar it into literally everything.
It's the future of parts of the web, not the future of everything.
All cyclists should know the basics, but nobody falts them for choosing not to ride a tricycle once they can choose between tricycles and bicycles. Or choosing to use a tractor trailer instead of a bike if that's what they need.
JavaScript is the foundational language of the web. You can't build anything reasonable on the web without JavaScript. As far as I can see it will be with us for at least another 20 years.
I foresee JavaScript being with us for the next 20 years whether we like it or not. It is the language of the web. We may have transpilers of all sorts but it will always come down to JavaScript at the base.
That statement means we will all be using Web Assembly to manipulate the DOM...and then to do any scripting we will just be writing WASM? What am I missing here?
Javascript may be around, as a compatibility layer at the very least. I tend to agree with the sibling comment, though: WASM at the base, compiled from Javascript (and just about every other language you could want). WASM isn't something you'd be likely to hand-code, it seems like.
None of that changes this fact for me: JS/ES is completely irrelevant to me as a development language. I've learned a bit and found portions reminiscent of a few other languages, but I don't really have a practical use for it, myself.
I used to think that* but began re-evaluating it when I found out how much of the world's population first computer is/was a smart phone. The inevitability of a language originally tied to a web browser optimized for desktop computers seems a whole lot less certain to me now.
[*] Not sure if I was right before or after, check back in a few years :)
Also, I think the idea that Javascript and HTML, languages designed specifically to markup and manipulate web documents, are the right tools for native app development is misguided as well.
I'm not saying JS doesn't have more general use constructs but HMTL/JS always feels like a strange, uncomfortable way to describe native UI. I guess what I'm saying is that you tend to feel the compromise.
In the end, I just think the language and tools used by the teams that build core apps for a platform will always beat those designed to abstract away what makes the platform special and compelling.
Both Android and iOS majorly use XML to describe layout, and constraint-based layout on both platforms is essentially flexbox (CSS).
Instead of a common standard we have 3 competing stacks.
Having developed several hybrid and native apps on both platforms, I can say that usually the worst layouts are done by devs with experience only in one platform. From a high level, it's easy to accomplish the same thing on all platforms, animations included. It would be a ton easier if they just would actually converge.
Storyboards and xib files use XML as a serialization medium, but you never actually work with the XML directly, it's literally just an underlying file format and the only reason it's used over a binary format is to make VCS merge conflicts easier to deal with. And more importantly, the actual built iOS app does not contain XML. Instead the build process constructs the view hierarchy based on the storyboard/xib (just as the interface builder editor does) and then serializes that to a binary plist (this is why UIView and UIViewController conform to NSCoding).
At Life360, we've started really seriously using the beta programs for both iOS and Android, and I've got to say that the iOS experience is terrible in comparison to Android.
In Android, our beta users download the app from the Play Store just like normal. The app automatically updates and for them, performs basically exactly like a normal app. On iOS, every update has to be a manual intervention for a beta user.
Look, the whole point of our beta community is to get early testing on new code. If half or more of the community put off updating for a few days because it's an annoying process, that's the exact opposite of useful. And it's worse than that -- I have no doubt that a great many of our beta users are now significantly behind our normal production users, because normal production users get automatic updates and beta users don't.
I've done React Native, it is beta but Ive dealt with XCode builds breaking when upgrading versions multiple time, also XCode builds need to pass and bad builds are not hard to come by, fixing XCode builds can be painful, for example you have to download multiple gigabytes of Xcode to support the latest iOS version, Android isn't that much better to be honest, but shipping makes it all worth it!
Even one 'silly' rejection is enough for me to consider the review process problematic. I've seen the same app pass review many times, and then suddenly it's rejected after a routine bug fix or minor update.
Yes, there's an appeal process, and yes, it's much faster than it used to be. But it has happened enough that I can't confidently predict how long an update might take because of uncertainty with the review process.
Working with a team of 5 developers and a rotating group of 10+ testers using personal devices, I can assure you provisioning profiles and certificates are a huge pain in the ass.
I agree there are quite a few problematic areas of this article (It reads like a advertisement for the author's app to me also), but a few of the negatives he listed are issues I've encountered in my career in iOS Development, albeit a career much shorter than yours.
> Provisioning Profiles
Provisioning profiles are still an annoyance if using tools such as Jenkins to compile and distribute builds, as xcodebuild has to be used to build the app. This forces you to manually set up the profiles and consequently run into many of the problems that have been solved with automatic signing. This also affects ad-hoc deployment as the process of adding new testing devices requires the generation and download of a new ad-hoc provisioning profile onto the Jenkins machine.
>Without the author listing the reasons for rejections it's hard to draw a conclusion here but complaints about rejections are usually BS.
I don't think this is the case of all apps. In the past few months my company has easily over ten rejections, due to the fact that our app targets a niche that the reviewers are not knowledgeable on. For instance, we received two rejections in the last month over the wording of our background location services requests. We use industry specific keywords that reviewers did not know, but users of our apps most definitely would know. It is true that these issues are generally sorted out easily, but we still receive rejections and it can get frustrating.
Regardless, the author stated he received 7 rejections before being approved. It seems to me that if the author's app was rejected this many times, he failed to follow Apple's app review guidelines in some form (Complete conjecture of course).
Game are still native. If you take Unity or Unreal engine 4, as of today it compile against metal for the Mac/iOS renderer. So yeah, actually game development is ahead of applications in term of crossplatform dev.
Probably true, and I'm so glad we have Apple in this industry. Otherwise everything would be optimized for ease of development instead of the end user experience.
That might explain how they got around the horror that is trying have have complex, flexible styling across several major Android versions without every single thing you do being entirely broken on one or another. I'd wondered why the various things I'd tried kept actually working. That'd do it.
I don't believe that this is accurate. It starts a V8 engine, not a Chrome engine, and renders (on the standard framework UI loop) using--as one would expect--native controls.
If you want to use a WebView, you must invoke a WebView.
I don't know if you're aware, but Chrome uses V8 to provide that functionality. Perhaps this is a Chesterton's Fence situation you should think about a bit?
(Though, as the sibling comment notes, it uses JavaScriptCore, which is Webkit's JavaScript engine, not V8 at all.)
Sorry, I'm fully aware of what V8 is (I actually embedded V8 once myself). By "V8 engine", I meant an engine containing V8, among other things such as a renderer. Bad wording, my mistake.
React Native doesn't contain a renderer in the Chrome-y sense of the term, to the best of my knowledge. It wraps native APIs instead. Am I missing something?
You're stretching. Chrome calls native APIs to render a rasterized view. React Native calls native APIs to render native widgets in a native window, i.e. an Android activity.
They actually ported JavascriptCore over to Android. The only time it uses V8 is if you run the code through the Chrome Debugger. Not sure what the benefit was perhaps performance or lower disk usage.
Nope. React native doesn't use webviews to render its ui. Business logic and view configuration are in JavaScript but all rendering and event processing is done in native. Also it's easy to wrap native components and insert them, something you just can't do in a webview.
Walled garden, monopolistic practices, favoritism, planned obsolescence. None of these things are a net gain for the end user. They do it better than anyone else, but it's still the same shit.
The latest version of iOS runs on all iOS devices back to the iPhone 5 -- introduced in 2012. How many Android phones still get updates from their manufacturer 5 years later? When Apple releases a security patch, it's available from day one to all users worldwide over the air. Can you say the same for Android?
I hold no opinion on "planned obsolescence", rather I want to separate OS from vendors. Vendor support is not a feature of the software it is a feature of the Vendor.
Android is open for anyone to do anything with, and there is no way to force someone to support something after they release it any more than it is possible to get them to not use Android in the first place.
If we look at Apple, Samsung, LG, HTC, etc... independently as companies I am sure some have crappy upgrade policies and some have great policies. If you want shop around for it, look at reviews for other phones.
If you don't want it, like if you are planning on installing your own OS or have other plans for the hardware then this is misfeature. It becomes a thing you have paid for but will never use.
Vendor support is not a feature of the software it is a feature of the Vendor.
Whether I buy a computer from Dell, HP, Lenovo or any other PC vendor, I still can get upgrades and security patches from Microsoft. I don't have to wait on the vendor for updates.
we look at Apple, Samsung, LG, HTC, etc... independently as companies I am sure some have crappy upgrade policies and some have great policies. If you want shop around for it, look at reviews for other phones.
Tell me one Android vendor who supports their phone with security patches for five years?
Windows is also locked down so that Dell, HP, Lenovo, etc... cannot make arbitrary changes to it. If they could they would like break the update mechanism.
I have seen plenty of preinstalled crapware from all those companies that never gets updated.
You can install your own Android base on the majority of Android phones? Including full support for Google Play Services? What about all of the chipsets that only come with binary blobs that the manufacturer has stopped supporting?
Are you really comparing the ease of clicking one button to upgrade Windows or iOS devices with using some semi supported "Android" OS that may or may not be supported for your phone?
> Apple, Samsung, LG, HTC, etc... independently as companies I am sure some have crappy upgrade policies and some have great policies.
Well...yes. Great upgrade policies: Apple. Crappy upgrade policies: Samsung, LG, HTC, etc.
Let's look at the flagships:
Apple: iPhone 5 from 2012 supports their newest OS release.
Samsung: Galaxy S3 from 2012 supports Android 4.3 and 4.4 (depending on model). Those are 2012 and 2013 OSes.
HTC: One X from 2012 supports up to Android 4.2.2.
LG: Optimus G from 2012 supports up to Android 4.4.2.
Google itself: Nexus 4 from late 2012 supports up to Android 5.1.1. A maintenance release from last year, with a base OS release 2.5 years ago...but certainly better than other Android vendors.
Android itself is still being updated as far back as 4.4.x, but that doesn't help much when the vendors aren't picking up the updates (and installing LineageOS tends to lose access to some of the features I paid for).
Most of them do, but usually only for a year or two after the release of a particular handset, and more for their flagship models than their more obscure ones. In most cases, those updates include a single major OS version jump, and maybe a year or two of security patches after that point.
> The latest version of iOS runs on all iOS devices back to the iPhone 5
Have new iOS versions stopped getting aggressively slower on old devices yet? Technically running but in a broken way doesn't stop it being planned obsolescence. If that did change then great, more people should be made aware.
Apple does a crazy amount of work to keep iOS running on as many devices as they can. Speaking as a developer, I wish they'd be more aggressive about dropping support for older devices.
But even if the new OS runs slower on old devices, that's not even remotely Planned Obsolescence. Planned Obsolescence means they deliberately make older devices run badly in order to drive upgrades. But there's not even a snowflake's chance in hell that Apple is doing that, and saying they are is pretty insulting to all the work they do ensuring the OS is at least usable on those devices. The simple fact is, as devices get more powerful, the OS expands to take advantage of that power, and so when you run the OS on older hardware it's now doing more work than it used to and frequently ends up slower.
I've told this story before, but I'll tell it again. I was an iOS user from day 1. Switched to Android when Apple refused to release a large screen device. I used multiple Androids over 2 years (HTCs, Nexus devices), and while I could do some geeky things with them they all had issues. Battery life was terrible. My Nexus 5 would randomly have a Google process spin out of control and kill the batter in 5 minutes. Updates tended to make the device not work as well (my Nexus 7 sits in a drawer after becoming unusable from updates).
I finally switched back to an iPhone, and realized how silly I was trying to convince my iPhone using friends to switch to Android. It just works. My friends don't care about kernels or custom ROMs. They want an OS that works, is secure, and stays updated. iOS does that. Apple will have to really mess things up for me to leave iOS at this point. For something I interact with on a daily basis, I don't have the time or the patience to deal with Android.
I like iOS itself (I have an iPhone 6 through work). I'd feel smothered using it as a personal device, though. Off the top of my head: it doesn't give me direct access to my on-device files, allow external storage, provide a relatively-unrestricted MTP share when plugged in, allow external app stores, or let me run a server (I sometimes run sshd for wireless file transfers, or an SMS proxy to send and receive SMS from my PC).
The things that iOS does, it arguably does better than Android. The things it doesn't do are what have kept me away.
I will admit that the lack of file system access was a bit difficult to get over when coming from Android - but it comes up rarely and is easy to work around (store the files on something else icloud dropbox etc..).
External storage seems to be pretty rare on Android though?
My #1 complaint about iOS is that they don't really allow other browsers.
> External storage seems to be pretty rare on Android though?
Not too rare. Google doesn't like it, so their stuff usually doesn't have it, but Samsung, HTC, and LG seem to have it in most of their flagships, anyhow. Maybe a generation skipped, here or there. It's not guaranteed, but not rare. I checked some budget phones from Blu, for the other end of the price spectrum. Some of those have microSD slots, too.
Exactly my first thought on reading the headline. "Oh, really? Then thanks for prioritizing my battery life and general UX over cheaper app development, Apple!"
Exactly. I remember hearing "eight megs and constantly swapping" as a joke, I think for anything javascript app related I can now say:
8 watts and constantly increasing
The amount of energy javascript pages now take makes me in some ways wish we had the ease of blocking crap like flash back in the day to not make my fans spin.
Also a webpage or app taking up 900MiB of memory? Really, this is what I want? Hell no, i'll stick to what I have thank you very much.
Certain web developers are an interesting breed of late.
Apple is hampering web apps. I am so not glad we have Apple in the industry slowing things down. They didn't mention anything web related at the last WWDC. The web is the future, not their little sandboxed world.
Why are you expect Apple to announce web-related stuff at WWDC? Besides the fact that the web isn't really what WWDC attendees care about, WebKit is also open source and you can watch development happening. Yes, sometimes Apple does work on a big thing that doesn't actually land on the open source project until they announce it, but that's usually when it's being done to support some other hardware or OS feature that they haven't announced yet.
If you want to see what's going on in WebKit, just check out https://webkit.org. A simple way to follow along is to read the "What's New In Safari Technology Preview ##" blog posts (and install the Safari Technology Preview to actually try this stuff out).
Yeah, and last year they had a session called Extending your App with Safari App Extensions (https://developer.apple.com/videos/play/wwdc2016/214/), as well as Apple Pay on the Web (https://developer.apple.com/videos/play/wwdc2016/703/). So they still do have the occasional web-related session. But for the most part there's not much need to be talking about web stuff at WWDC, because most development of the web stuff happens in the open already throughout the entire year, and WWDC isn't being attended by web developers anyway, it's being attended by app developers.
I remember when they announced multipath TCP during WWDC. It sounds like you are saying that WWDC is only for app developers and they just don't have a conference for web developers. I thought they cared about the web, they used to.
If the title were literally true it would be a positive mark in favor of Apple, in my opinion. A good many of the paradigms in web development exist, it seems to me, simply because the desire for cheap apps built with cheap labor outpaced the platform on which these cheap apps are built. Whoever thought using the browser as a substitute, psuedo, or virtual OS was a good idea?
What's funny is Apple's original plan for iOS was that additional functionality would only be delivered via cross-platform web apps.
With iOS 1 lot of developers thought Apple was terrible for promoting web apps and that native should be the way forward. And so the app store and native apps arrived in iOS 2.
Now, apparently, Apple is terrible for having native apps and that web apps should be the way forward.
I'm still convinced this was BS, and they were late with the SDK. I cannot imagine anyone inside Apple thinking they could get away with the quality of IOS 1 (well iPhone 1.0) web apps.
It is. There have been interviews. They didn't have the SDK ready (it was a total mess on the preinstalled apps). When people demanded a way to develop they pushed out web development because they could do it fast while they got everything else documented and into a consistent state and secure.
It sounded like they always expected to do native apps, just not nearly as fast.
Apple has abandoned the web. WWDC 2016 didn't mention the web once. They are holding web apps back. They still haven't announced service worker commitment for Safari. What a joke.
That isn't "holding web apps back" in my opinion, it's refusing to encourage terrible development paradigms and ecosystems. Good for Apple (and I'm saying this as a person who generally doesn't care for the company).
Just because someone has put feature X in their browser doesn't require all other browsers to implement it. If it did I'd still be able to use VBScript.
As I watch HN I see people talk about things that are 'missing' in Safari and they should be able to do from JS and many of them horrify me. I don't want random sites to know the light level of the room I'm in. I don't want them recording audio. Log running background tasks? Didn't we learn from TSRs? I don't trust random devs with that.
One of the intentions of Netscape, or potentials Microsoft feared, was that applications (though not quite what that means today) could be run in the browser on any OS. This was one of the primary motivators for MS to release IE for free with a huge marketing spend. They feared the potential for businesses to move away from Windows if they didn't need dedicated, native applications.
My point being, this isn't new. Since interactive applications first happened in the browser, this has been the objective whether we like using these things or not.
Which happened to a good degree. If it wasn't for the web it would have been WAY harder for me to switch to the Mac in '04 or so because so much of what I did had moved to the browser I wasn't leaving as much behind.
>Put simply, if your users never complain about the performance of your app then it is fast enough
Suppose the users aren't aware that your app is wasting their battery power, because of it's bad performance?
Suppose your users don't complain because ~90% of software is written slow, and so they expect sluggish response. Maybe you could be getting rave reviews about how responsive your app is. Example: saw recently a discussion on reddit where a guy did an Android app in rust, instead of the usual Java/Unity etc. People who tried it out all remarked "wow that was the fastest opening game I've ever clicked on!"
CPU designers have been doing amazing things with hardware, let us not waste it.
I remember two years ago I was playing a fun little game on iOS and it felt nice and fast and I had no problems with it.
Until I got complaints from the network manager at my work because it seems that when you skip the video ads it continued to play them in the background and used up the very meager bandwidth we had at the time.
It's very easy for a simple accidental mistake to cause all sorts of issues while the app still feels "fast".
(I'm still kind of surprised/disappointed that got through app review).
Also, just because something is fast enough that people don't complain doesn't mean that it's fast enough that people are happy. I'm used to the speed of my TiVo, it could be MUCH faster.
The truth is: people are used to poorly designed things that don't go very fast. That doesn't make it OK to give them more of them.
It was either a horrible bug (because it used a LOT of bandwidth and would have cost me big $$$ on LTE) or outright fraudulent (I'm not paying attention but they're reporting I am to get paid).
Only in volume, not percentage, there are just more people joining the marketplace. Apps vs mobile web as share of user experience is dropping.
Makes sense after all, its easier, faster, cheaper, less storage used etc... and more accessible to get to something on safari or chrome than publishing an apk or ipa
Now, the real question to me is where are people spending their time? Pretty much all in apps, but only for the top 10-20 apps in the marketplace - which means that unless you have a top 10 app that is going to pull people off of their FB/SNAP etc...app and onto yours, then don't waste your time.
> You get to utilize your existing JS, HTML, and CSS skillset to develop a single codebase that runs on both iOS and Android.
This always reminds me of the quote: consistency is the hobgoblin of small minds.
You see this "consistency" argument rear its ugly head all the time. I can remember hearing it when GWT was being pushed ("you can use your Java code on server and client"). The reality of course is far from idyllic. But that was completely predictable.
You also see this argument with Node.js.
The problem when you try and broaden something like this is it's incredibly difficult not to end up with something that doesn't simply combine the worst of both worlds.
Now I'm not an iOS/Android dev but from the sidelines I tangentially keep abreast of what's going on. It seems like React Native has some real potential here. Like some benchmarks I've seen show there's not much of a performance hit. If (and that's a big "if") this turns out to be the case, pulling this off would be a rare feat of success.
Now even if it succeeds, there'll still be a cost. I'm sure there are some things that are easier in iOS/ObjC/Swift and Android/Java. For one thing it would be difficult to abstract away the different memory management models (IMHO ref-counting rather than GC in iOS is a competitive advantage).
Anyway I don't think Apple killed Web apps or hybrid apps. Two things killed those:
1. HTML/CSS/JS is honestly horrible. Particularly layout in CSS (mainly pre-flexbox). Performance isn't great. People end up with Web apps with 1M+ DOM objects. That's just crazy.
2. Performance is just so much better on iOS/Android (rather than HTML5). Part of this is you know a lot more about the target platform than with a Web app.
Yeah, I think the author is kind of out of date. Even people who go the cross platform route nowadays don't use Cordova, where PhoneGap went to die, they use something modern like React Native, which doesn't have the HTML performance penalty.
Occasionally I find an article on Hacker News that I both strongly disagree with, and feel I have enough domain knowledge to speak intelligently about. This is my opinion, and may be different from yours.
> Make No Mistake, Going Hybrid Is The Right Choice For The Vast Majority Of Apps
I think that is very presumptuous. Maybe it is for some developers. I used Cordova sparingly a few years ago. Most of my hybrid development going back to 2012 is using Appcelerator Titanium. In fact, at this very moment I'm putting off working on a project built on the Appcelerator Platform, because of the giant headache that it has caused me.
Here are some of the reasons that I'm in favor of native development, with completely separate codebases for each platform, possibly using some shared libraries when appropriate.
1. As alluded to in the article, even with hybrid you have to put up with Apple BS. And it turns out, Xcode is not completely terrible; eg. in 2017, building a native app, you don't have to worry about provisioning profiles (much), because Xcode handles this for you. I was shocked when I discovered this after developing hybrid apps for years. If I have to learn it anyway, I might as well use it.
2. Quality/reliability/ease-of-use of third party libraries is higher. Yes, there are legions of Javascript developers out there, and some of them are trying to build mobile apps. There are also a great number of native developers out there and (trying not to ruffle too many feathers, and with no data to back this up) they are on average more experienced than the average javascript developer. They are also writing COMPLEX apps, and as a result we have a large ecosystem of good libraries that do a lot of the things that one might need to do when writing a mobile app, and they probably work out of the box with your toolchain, because the developer is using the same toolchain as you. Just drop it in, and use the API.
3. Hybrid app frameworks do not expose the full feature set of native platforms. Yes, Appcelerator just released "Hyperloop" to the masses which claims to do just that. I haven't tried it. Why make native calls through Appcelerator when I could just make native calls to the OS?
4. Hybrid app frameworks have their own bugs, and limitations that require strange workarounds. One might think that running into these would be uncommon. All it really takes is one, if you then have to sidetrack into learning about the codebase framework you are using, potentially rebuilding from source if there's no way to work around it at the top level. By the time you get it all sorted, you may as well have just done native. Sure Xcode has bugs and limitations too, and Appcelerator has definitely improved in this area over the last 5 years, but with layers of abstraction comes layers of new problems.
5. Technical support is easier to come by with native. Having a problem with something complicated? Good luck finding an existing question and answer of Stackoverflow. There just aren't enough knowledgable Javascript devs doing complex things with hybrid apps compared to native. Also, the hybrid app development ecosystem is fragmented: the problem you are having with Cordova is probably not the same as the problem I'm having with Appcelerator. Or maybe it is, but it's not readily apparent.
6. Native toolchains are superior to hybrid ones. I'm stepping out a little bit here. I abandoned Appcelerator Studio years ago in favor of the CLI, so I don't know what I'm missing there today. Well, I do know that I'm missing a decent debugger. Maybe that is in Appcelerator Studio - I have no idea. Feel free to call me out on this one.
In summary, hybrid is probably the right answer for SOME apps, and SOME developers. Based on 5 years of experience building hybrid apps, there are very few apps that I think wouldn't have been better (without consuming additional budget) as native apps. There are too many unknowns for ...
I've been using Titanium for years now. Since the very early days. It's certainly had its fair share of painful upgrades, but I've learned a lot of Java and Objective-C in the process as I've built a few cross-platform native modules to do things the main SDK can't do.
And recently, they've opened up 'Hyperloop' to the (now) free Indie Tier. Hyperloop allows direct access to native iOS and Android code, modules, pods, Frameworks, jars, aars, etc. right from within the Javascript code.
I used Angular a lot too and have built Ionic apps with that knowledge too. But, my overall opinion is that Titanium is by far the best. (As long as you pick a good stable SDK version! ;) )
Wait -- hyperloop is alive and well?? How do you like it? I may have to revisit Titanium, it's been a couple years but I had good experiences with the platform pre-hyperloop.
I don't really disagree that they have the right idea, and are the best that I've tried in the hybrid space. I've just spent so much time fighting the platform that I feel native is a safer, more powerful, and better option.
I disagree with the author that "the Hybrid approach is the right choice for your next app".
Speaking from personal experience, the time it takes to create workarounds for UIWebView/WKWebView is only slightly less than the time to get familiar with Swift/UIKit. With knowledge of mobile paradigms it is easy to pick up Java/Android.
The advantages of creating two separate native apps are designs that fit each individual platform, better battery life, and overall better performance.
The author's time to market using hybrid development was less than the time it would've taken to learn iOS/Android native development and ship. However, the time difference is not as large as one may think. By continuing to invest in hybrid app development the author didn't learn valuable iOS/Android native app development skills and created an app that isn't as performant or designed to fit each platform.
the time it takes to create workarounds for UIWebView/WKWebView is only
slightly less than the time to get familiar with Swift/UIKit
This times a thousand.
I have wasted untold hours on clever paperclip-and-gum techniques to get WKWebView to be something it isn't: predictable and usable.
I still develop hybrid apps for clients (glorified web pages, really) but for personal projects I will never, ever go back. Kicking myself for not learning Swift earlier.
When my job looked at the JS app idea (3 or so years ago) that was one of my big takeaways. If we made a web app, we would spend just as much of not more time polishing it until it felt native than we would have making it native on the platform in the first place. It wasn't a highly complicated app.
"The author's time to market using hybrid development was less than the time it would've taken to learn iOS/Android native development and ship."
So in other words, he spent less than 50% of the time needed to build both an iOS and Android app (if we assume learning Java and building the Android app will take equally as long as learning Swift and building the iOS one). Sounds like a huge win if one can live with the other tradeoffs.
I think Hybrid has it market and it makes sense for some apps, but for medium/big companies you probably end up with a native app (or a hybrid app with more native).If the app is native you can do more things in the device, there is better documentation for how to do complex things and you don't have to use Javascript. Swift and Kotlin are much better languages to use for apps. But I think the main point is that apps, nowadays, most of the logic of the app resides in the server, so the apps are only front ends. And to make a nice front end with smooth animations it is easier to do it native, because animations are different for every platform, so there is not much code to share.
The whole article misses the point. The entire purpose of WKWebView is a compromise that let's the user take advantage of all of the features of Safari within an app -- passwords, bookmarks, shared cookies between the view and Safari, native performance -- without the security implications of random apps having access to everything you type in. If you enter your password into a web view, the app has complete access to it. If cookies were shared in a web view like they are in a WKWebView it would be a major security vulnerability.
Sure there is... the article even said that WKWebView and Safari are faster than his Samsung device. The problem is not that the browser isn't fast, the problem is that he wants to make a sub optimal cross platform app that's not optimized for either iOS or low end Android devices that most people are buying.
Boy is it time for another round of "Hybrid Apps, Wave of the Future!"?
Disclaimer: I've been writing and shipping iOS apps since shortly after the iOS SDK existed, and writing and shipping Android apps for the last couple of years. My opinions may be biased.
First, a couple of observations to get out of the way that may support author's thesis, but IMO not really:
- A good portion of existing native apps should not be apps at all. These are apps for services that are infrequently used, and should have been websites the entire time. Note that I'm saying they shouldn't be apps at all - native or hybrid - they should simply be websites. Because of the friction of installation, shipping an app for something users will only very occasionally use, is pointless.
- If your apps are strictly by-the-numbers CRUD apps without background activity, then a hybrid approach is likely the best bet.
Now that that's out of the way...
> "A Hybrid version of an app will never be as fast as a native version of the same app, but it doesn’t matter as long as the Hybrid version is fast enough."
This assumes the lack of competitors who are willing to put in the effort to make a performant app. It should be noted that janky, slow UIs that are "good enough" were the norm before the iPhone came around and raised everyone's expectations.
If you're building an app for Comcast or your local utility company - where competition is definitionally non-existent, then yes, it doesn't really matter as long as the hybrid version is fast enough.
For markets with competition, this simply produces a large window for someone to eat your lunch.
> "You get to utilize your existing JS, HTML, and CSS skillset to develop a single codebase that runs on both iOS and Android."
This seems user-hostile. For all of Apple's warts, one of the great things they did around the iPhone is to rebalance consumer software development away from developer convenience and towards user convenience.
The 90s and early 00s was defined by software that was difficult to use, engineered to be just "good enough", and largely the process was geared around developer ease rather than user satisfaction.
Yes, as devs we want all kinds of shortcuts to make our lives easier - and by all means we should pursue them - but the market in many places no longer tolerates the UX compromises of certain shortcuts, and consumers have come to expect apps to respect their platform's UX standards and have a high performance bar.
Case in point: Java apps also allowed devs to ship multi-platform from a single codebase, anybody here actually enjoy using those things? Practically nobody does that any more.
> "Viewing changes on your device during development is nearly instantaneous."
This is legitimately a great feature of web dev vs. native. There is a lot of work being done on iOS and Android to shorten the preview cycle - but it's nowhere near web-quick (and is unlikely to ever be).
But again, this is a developer convenience, not a user convenience, and like all developer conveniences, it should only be pursued without harm to user experience.
> "You can push updated JS, CSS, HTML, fonts, and images directly to all of your users without needing to recompile the app’s binary and getting App Store approval."
This is the part I wanted to touch on most: DO NOT DO THIS. This is explicitly against App Store TOS and can/will get your app rejected or pulled without notice.
You cannot ship features to the App Store without a binary update. This is also not a hypothetical - Apple has recently started ratcheting up enforcement on apps that significantly modify functionality while bypassing the review process.
If you want to build a hybrid app despite my objections, by all means, but do not use code push features and especially do not use it to bypass A...
>> "You can push updated JS, CSS, HTML, fonts, and images directly to all of your users without needing to recompile the app’s binary and getting App Store approval."
> This is the part I wanted to touch on most: DO NOT DO THIS. This is explicitly against App Store TOS and can/will get your app rejected or pulled without notice.
I just came here to say the same thing.
I guess it's still useful in 'enterprise' scenarios though, where you are distributing apps to a restricted set of users by some other means, such as through Microsoft's Intune. I don't know why Ionic Deploy and CodePush don't make this plain though.
Edit: I just checked the CodePush FAQ, and they seem to be interpreting the Apple developer agreement such that updates outside of the app store are allowed as long as they don't radically change the app [1].
Personally, I'd be really wary of going down this path, worried that Apple or Google would pull the rug out from under it. Anyone here had any apps rejected or pulled for using CodePush, Ionic Deploy or something similar?
I wrote the article and just saw that there was a discussion about it here. I actually primarily tested it on an LG G2 and Motorola Moto G 3rd gen. Both of these phones are fairly slow, and my app runs about as quickly as any other app I open on them.
I worked on a cross-platform mobile development tool called Nomad for Visual Studio (from Red Gate Software) for a while back in 2013, since retired. Back then hybrid mobile apps, for the most part, absolutely sucked balls in comparison with their native counterparts. Performance, in particular, was often choppy, and it largely wasn't possible to offer an anywhere near native user experience.
(I know, I know: everyone's going to point at Untappd, which was 2013's poster-child hybrid app, and talk about how awesome that was, but whilst it was decent, it was still noticeably hybrid. And, yes, there were and are companies selling native controls that can be used from a hybrid app to make things easier/better/more performant.)
The experience of working on Nomad taught me one thing: if you were serious about mobile app development, and you wanted to provide users with a great experience, your only option was to go native, be that on iOS or Android.
Four years has passed and, nowadays, the situation has improved quite a bit for hybrid apps. Still, it's disingenuous to suggest that most apps would be better as hybrid.
Sure, your app might run "fast enough" for many scenarios, and the user might not be able to even tell the difference between native and hybrid implementations, but if your hybrid version burns 10 times as many CPU cycles as its native equivalent would you're caning the battery life of the device, which is an aspect of mobile performance that seems to escape a lot of people. Speed is one thing, but how long you can continue to use the app or device also matters to people. (I say this as somebody seriously considering porting a couple of HTML5/JS games to mobile at some point in the future.)
This problem becomes particularly pronounced if you're building an app - and this goes far beyond games - with any kind of fancy media component, custom drawing, etc., any kind of rendering, doing anything cool/fancy with music or sound. You can take advantage of WebGL and shove a bunch of work onto the GPU, which will almost certainly do better battery-wise, but if you have some idea that you can just hack something cool and flashy together with HTML5, JavaScript, and CSS, and it won't drain the battery and make the device quite warm, you are likely to be disappointed.
I will agree that iOS is an absolute pain in the neck to develop for when it comes to doing anything remotely interesting with web technologies, regardless of whether that's as a hybrid app or even just in browser. But that's a long rant for another day.
I wonder if there's a way to do that for web apps? Both Safari and Chrome have pretty good support for remote debugging devices but I've not noticed anything like this for tracking energy usage. It would certainly be a super-useful addition.
286 comments
[ 5.3 ms ] story [ 261 ms ] threadeBay's app, for example, adds little for most users.
Battery usage can still be a problem even if the app appears to run smoothly.
"Well, let's say you can shave 10 seconds off of the boot time. Multiply that by five million users and thats 50 million seconds, every single day. Over a year, that's probably dozens of lifetimes. So if you make it boot ten seconds faster, you've saved a dozen lives. That's really worth it, don't you think?"
http://www.folklore.org/StoryView.py?story=Saving_Lives.txt
That's probably putting it a bit too strongly, but "nobody complains" is probably putting the bar too low.
More power to you, but I find the short pauses in apps the worst. If some function is going to take time to run and I expect that, absolutely, I can walk away and come back to it. I do this frequently. But these are not the sorts you generally see on phones - you get terrible 7-10 second pauses as something slow launches, talks to a slow server, thinks weirdly hard about something because of a slow loop, whatever.
Especially when unexpected, 7 seconds is insufficient to task-switch, so yes, you end up staring at your phone.
The thing about phones is the immediacy of using it. Nobody uses a phone like you say.[0]
[0] Okay, nobody is a definitive. Almost nobody, then.
The idea I'm really calling into question is "So if you make it boot ten seconds faster, you've saved a dozen lives." Waiting for your phone to do something isn't like being in a coma, where the time is irretrievably lost and provided no benefit (beyond what it might have allowed recovery wise), nor is it like sleep, where we spend a significant portion of our lives doing it and we can't do anything else during that period (even if that period itself is beneficial).
Delays are annoying. Making delays shorter is good. Saying shortening delays saves lives worth of time is problematic. Even the original commenter acknowledged that was probably reaching (it wasn't his quote).
This is a problem. Some user not even know what a fast app look like, neither have the hardware (hello old PC, hello cheap Android) or blame themselves for any problem or just assume "is supposed to be like this".
Take for example the Android emulator (and in this case, using developers). In the moment I launch it, the FIRST TIME, i instantly look for a alternative (was impossible slow). However, how many developers stick to it, and have even less powerful machines than mine?
Or using something else: How many people think that miss keys in the keyboard is his fault and not a problem with cheap rubber domes? And how many know exist mechanical or have used a old quality keyboard?
Ignorance of the users is NOT their problem. Is OURS.
Apple completely fucked over AS3/Flash. Adobe launched multiple attempts to work with apple to build out a system to launch swf files on a iOS device. Apple could have helped. Adobe should have played hardball and yanked photoshop [+studios] from the osX.
The problem rather is in the Apple users that accepted this behaviour from "their" company.
I'm sure it could be made to work great, but it never did.
https://en.wikipedia.org/wiki/SWF#Licensing
Android was hit or miss depending upon the specs of the device.
These are probability the same developers that were writing sloppy Flash banners a decade earlier.
Compare that to being at the mercy of a company like Adobe that bundles at least 3 different JavaScript interpreters, a full blown WebKit and who knows what else to Photoshop. All while having a custom made cross platform UI layer across all of their apps.
Nowadays of course we have CPU core swallowing and battery draining JavaScript ads, along with massive JavaScript bloat in general. For the heck of it I just went and had a look at one of my own pages, which runs an HTML5/JS/CSS game, and includes Adsense. It downloaded 633KB of JavaScript. By today's woeful standards that's not even particularly bad. To break it down a bit though, 52KB of it is scripts I use directly, of which 47KB is required for the game. The other ~5KB is FontAwesome, which I use for icons on the menu buttons. The other 581K? Well, Adsense itself is also fairly small (about 35K for two scripts), which leaves the rest - the vast majority - which is loaded by the ads themselves.
Like you, I've come to realise that it wasn't the tool/platform, but the people building for it. Clearly the best developers are not building ads. It feels like there should be some scope for disruption here.
At the time, it was such a great idea (in theory)
A few really big indie hits were however written in flash and related languages.
Remember how in the early days it was a "big deal" that android phones supported flash but iOS didn't? Tech people used to think that was important, and it netted android some sales, but in the end everyone had to admit that it was kind of a bad idea.
Today things are different since most site use html5 instead but back then iPhones were seriously crippled on the web.
Shortly after, most of those sites released normal mobile versions anyway.
However, as a platform the player was lean and optimized. A lot of people wrote horribly inefficient things with it, which gave it a reputation for being power hungry and slow.
There were additional performance issues on Mac desktops where certain APIs for video playback were blocked.
Flash the development environment was pretty great, and nothing comes close to it today. The closest I can think of in terms of ease of picking it up for artists/designers/etc is Unity, but it really is built for 3D first.
This is complete nonsense.
Adobe screwed over Flash and the number of major vulnerabilities discovered in the decade since iOS 1.0 has proven this to be absolutely the right decision. Apple has the responsibility and the right to put their user's security above and beyond the needs of a minority of developers.
Also your point about AS3 versus Objective-C is hilariously stupid. Anyone experienced in a platform is going to find development quicker than someone who isn't. I would be 10000x faster building an app with Objective-C because guess what I don't even know AS3.
EDIT: 33 years ago, not 1970s.
Sad
Programmer productivity is measurable.
But my point still remains that people are more productive in the technology they know the best.
That said, I'll never miss Flash. The web became a much better place the day it died. Maybe it could have worked better on mobile devices? I have no idea, but I'm definitely not sad that Apple said no (because that kept it out from my Android phone too)
Granted, mobile devices were never a target for Flash games, so the biggest problem was that all the sudden our clients needed content to run on a new lower power device in addition to desktop browsers. Previously our biggest problem was clients that needed things to run in old versions of IE (IE6 anyone?!). Our last couple of Flash games that we built 5+ years ago are still far more impressive (on desktops) than any HTML5 game we've since developed (and we've developed A LOT of them!). GPU access was made available for the Flash player shortly before it died. A lot can be done now with WebGL, but wide device/OS/browser support is still a problem.
We've since branched a lot more into native app development where we can continue pushing the envelope visually. Our JS games continue to feel like they have handcuffs on them and still can't compete with Flash 5-7 years ago.
Why would Apple want that?
I think it could have been a contender for winning the 'cross-platform-mobile-dev-tool" war; but Adobe abandoned it along for the most part.
Apple never had an SDK to begin with because they thought developers would write their apps in HTML5/JS. Guess what ?
They were awful and users hated it compared to the native applications.
The experience was painfully slow and clunky, so by iPhone Software 2.0 they rushed a native SDK. Which you could see it was rushed because it was very lacking and buggy at first.
It wasn't a great idea to start a internet-only business in the mid 90s (with some obvious exceptions), but the same isn't true today.
What I've heard is that in 1.0 they were really different bits of software many of the applications had their own implementation of UITableView... basically things were a mess. So Apple put out the Web stuff while they got everything cleaned up and standardized and documented to the standard they want to give out to third-party developers.
>> There are some major advantages to the Hybrid approach: You get to utilize your existing JS, HTML, and CSS skillset to develop a single codebase that runs on both iOS and Android.
This is assuming you have a JS/HTML/CSS skillset.
>> Here’s some Apple BS we can’t avoid no matter what approach we use >> Xcode
I've done some React Native development and Xcode is almost entirely avoided.
>> Provisioning Profiles
It's been a long time since I encountered issues here as it's all managed by Xcode nowadays.
>> Needing to use TestFlight for beta builds
Why is this BS? You could also use Ad-hoc distribution along with something like Fabric for small scale beta tests.
>> The app review process. Admittedly, the app review time has dropped to about 2 days on average, but when your app gets rejected 7 times like Rizer did (for legitimately silly reasons), your patience can really start wearing thin.
I've been developing on iOS since about 6 months after the App Store became a thing. I've developer dozens of apps and submitted hundreds of updates. I can count on my fingers the number of rejections I've got and there were only one or two that were 'silly' (and those were fixed through a quick appeal). Without the author listing the reasons for rejections it's hard to draw a conclusion here but complaints about rejections are usually BS.
Overall I can't help but feel this was thinly veiled clickbait to advertise the authors app.
Almost entirely avoided still means you have to go out and buy a Mac and keep Xcode running on it.
I understand that some of these EULAs aren't enforceable everywhere, in the form of consumer protection laws inhibiting what's basically perceived to be bullying behavior. At least in the U.S. consumer protection laws are weaker, depending on the idea that when consumers are bullied, they'll spend their money elsewhere.
In a global market, asymmetric consumer protection laws aid bully behaviors. The countries were people are safe flaunting EULAs may have higher usage rates of software with unfavorable EULAs, rather than using alternatives with a more favorable EULA.
I totally understand not liking the license, but if you click the agree button when installing the software on non-Apple hardware, you're basically lying.
If you acquired Mac OS X legally how would this be illegal? I will admit acquiring it legally could be tricky, but that is not what we were calling illegal was it?
The (mostly-untested) theory is that clicking "I agree" on the license is a legally-binding contract between you and Apple. The Mac OSX license repeatedly says that a requirement of the use of the software is that it be used on Apple-branded hardware.
So, "illegal" based on unlicensed use of copyrighted material or based on breach of contract. At least, that's how I understand the argument.
Seriously, I can never take this argument seriously.
I can easily develop iOS software without owning an Apple computer...but I can't do it legally. I'm happy I'm not in mobile dev, and this is one reason.
So,you've pretty much established yourself as an expert in the ecosystem. That actually lends less credence to your counterarguments in my eyes. It's all too easy as an expert to overlook the pain points that you've become accustomed to, or did not notice as they were slowly layered up over the years. In my experience, the expert that rages against the system they use is far more likely to have valid input than the expert that apologizes for it.
That's not to say you're wrong. Just that in my eyes the likelyhood of you being right dropped as you explained how much experience you had (past a certain threshold. Amateurs often don't understand enough to accurately critique as well).
Same holds for the inverse: it's easy as a newb to consider everything as a pain point, even if it's a well designed procedure.
Sure, that's why I noted as much with my last sentence. :)
Seriously if your app gets rejected that much that you'd bitch about it, it's because you're not paying attention to what you're doing and/or are up to some shady shit. It's really not difficult to avoid.
All cyclists should know the basics, but nobody falts them for choosing not to ride a tricycle once they can choose between tricycles and bicycles. Or choosing to use a tractor trailer instead of a bike if that's what they need.
Boyancy is the foundational concept of naval transportation, but it's not the foundational concept of all transportation.
None of that changes this fact for me: JS/ES is completely irrelevant to me as a development language. I've learned a bit and found portions reminiscent of a few other languages, but I don't really have a practical use for it, myself.
[*] Not sure if I was right before or after, check back in a few years :)
I'm not saying JS doesn't have more general use constructs but HMTL/JS always feels like a strange, uncomfortable way to describe native UI. I guess what I'm saying is that you tend to feel the compromise.
In the end, I just think the language and tools used by the teams that build core apps for a platform will always beat those designed to abstract away what makes the platform special and compelling.
Instead of a common standard we have 3 competing stacks.
Having developed several hybrid and native apps on both platforms, I can say that usually the worst layouts are done by devs with experience only in one platform. From a high level, it's easy to accomplish the same thing on all platforms, animations included. It would be a ton easier if they just would actually converge.
Storyboards and xib files use XML as a serialization medium, but you never actually work with the XML directly, it's literally just an underlying file format and the only reason it's used over a binary format is to make VCS merge conflicts easier to deal with. And more importantly, the actual built iOS app does not contain XML. Instead the build process constructs the view hierarchy based on the storyboard/xib (just as the interface builder editor does) and then serializes that to a binary plist (this is why UIView and UIViewController conform to NSCoding).
Yeah if it's just Swift/ObjectiveC vs HTML/JS/CSS, then it's a moot point, just pick one.
However it's Swift/ObjectiveC/Java(Andorid) vs HTML/JS/CSS
The latter comparison is not even equivalent.
In Android, our beta users download the app from the Play Store just like normal. The app automatically updates and for them, performs basically exactly like a normal app. On iOS, every update has to be a manual intervention for a beta user.
Look, the whole point of our beta community is to get early testing on new code. If half or more of the community put off updating for a few days because it's an annoying process, that's the exact opposite of useful. And it's worse than that -- I have no doubt that a great many of our beta users are now significantly behind our normal production users, because normal production users get automatic updates and beta users don't.
Not a terrible assumption. There are way more web devs than any others.
Yes, there's an appeal process, and yes, it's much faster than it used to be. But it has happened enough that I can't confidently predict how long an update might take because of uncertainty with the review process.
> Provisioning Profiles
Provisioning profiles are still an annoyance if using tools such as Jenkins to compile and distribute builds, as xcodebuild has to be used to build the app. This forces you to manually set up the profiles and consequently run into many of the problems that have been solved with automatic signing. This also affects ad-hoc deployment as the process of adding new testing devices requires the generation and download of a new ad-hoc provisioning profile onto the Jenkins machine.
>Without the author listing the reasons for rejections it's hard to draw a conclusion here but complaints about rejections are usually BS.
I don't think this is the case of all apps. In the past few months my company has easily over ten rejections, due to the fact that our app targets a niche that the reviewers are not knowledgeable on. For instance, we received two rejections in the last month over the wording of our background location services requests. We use industry specific keywords that reviewers did not know, but users of our apps most definitely would know. It is true that these issues are generally sorted out easily, but we still receive rejections and it can get frustrating.
Regardless, the author stated he received 7 rejections before being approved. It seems to me that if the author's app was rejected this many times, he failed to follow Apple's app review guidelines in some form (Complete conjecture of course).
https://sensortower.com/ios/rankings/top/iphone/us/all-categ...
If you want to use a WebView, you must invoke a WebView.
And that V8 engine contains functionality which is surprisingly similar to Chrome.
Except they decided to reinvent the wheel.
(Though, as the sibling comment notes, it uses JavaScriptCore, which is Webkit's JavaScript engine, not V8 at all.)
There's always room for improvement, but it's not shit if you ask me. In my opinion it's the best mobile OS we've got.
The latest version of iOS runs on all iOS devices back to the iPhone 5 -- introduced in 2012. How many Android phones still get updates from their manufacturer 5 years later? When Apple releases a security patch, it's available from day one to all users worldwide over the air. Can you say the same for Android?
Android is open for anyone to do anything with, and there is no way to force someone to support something after they release it any more than it is possible to get them to not use Android in the first place.
If we look at Apple, Samsung, LG, HTC, etc... independently as companies I am sure some have crappy upgrade policies and some have great policies. If you want shop around for it, look at reviews for other phones.
If you don't want it, like if you are planning on installing your own OS or have other plans for the hardware then this is misfeature. It becomes a thing you have paid for but will never use.
Whether I buy a computer from Dell, HP, Lenovo or any other PC vendor, I still can get upgrades and security patches from Microsoft. I don't have to wait on the vendor for updates.
we look at Apple, Samsung, LG, HTC, etc... independently as companies I am sure some have crappy upgrade policies and some have great policies. If you want shop around for it, look at reviews for other phones.
Tell me one Android vendor who supports their phone with security patches for five years?
I have seen plenty of preinstalled crapware from all those companies that never gets updated.
All I am trying to say is that android, the OS is not the reason updates don't happen. The Vendor is and largely your point point agrees with me.
Are you really comparing the ease of clicking one button to upgrade Windows or iOS devices with using some semi supported "Android" OS that may or may not be supported for your phone?
Well...yes. Great upgrade policies: Apple. Crappy upgrade policies: Samsung, LG, HTC, etc.
Let's look at the flagships:
Apple: iPhone 5 from 2012 supports their newest OS release.
Samsung: Galaxy S3 from 2012 supports Android 4.3 and 4.4 (depending on model). Those are 2012 and 2013 OSes.
HTC: One X from 2012 supports up to Android 4.2.2.
LG: Optimus G from 2012 supports up to Android 4.4.2.
Google itself: Nexus 4 from late 2012 supports up to Android 5.1.1. A maintenance release from last year, with a base OS release 2.5 years ago...but certainly better than other Android vendors.
Android itself is still being updated as far back as 4.4.x, but that doesn't help much when the vendors aren't picking up the updates (and installing LineageOS tends to lose access to some of the features I paid for).
Do any android handset manufacturers ship updates?
Have new iOS versions stopped getting aggressively slower on old devices yet? Technically running but in a broken way doesn't stop it being planned obsolescence. If that did change then great, more people should be made aware.
> Can you say the same for Android?
This is about iOS's faults, not Android's.
But even if the new OS runs slower on old devices, that's not even remotely Planned Obsolescence. Planned Obsolescence means they deliberately make older devices run badly in order to drive upgrades. But there's not even a snowflake's chance in hell that Apple is doing that, and saying they are is pretty insulting to all the work they do ensuring the OS is at least usable on those devices. The simple fact is, as devices get more powerful, the OS expands to take advantage of that power, and so when you run the OS on older hardware it's now doing more work than it used to and frequently ends up slower.
People really have no context...
I finally switched back to an iPhone, and realized how silly I was trying to convince my iPhone using friends to switch to Android. It just works. My friends don't care about kernels or custom ROMs. They want an OS that works, is secure, and stays updated. iOS does that. Apple will have to really mess things up for me to leave iOS at this point. For something I interact with on a daily basis, I don't have the time or the patience to deal with Android.
The things that iOS does, it arguably does better than Android. The things it doesn't do are what have kept me away.
External storage seems to be pretty rare on Android though?
My #1 complaint about iOS is that they don't really allow other browsers.
Not too rare. Google doesn't like it, so their stuff usually doesn't have it, but Samsung, HTC, and LG seem to have it in most of their flagships, anyhow. Maybe a generation skipped, here or there. It's not guaranteed, but not rare. I checked some budget phones from Blu, for the other end of the price spectrum. Some of those have microSD slots, too.
The amount of energy javascript pages now take makes me in some ways wish we had the ease of blocking crap like flash back in the day to not make my fans spin.
Also a webpage or app taking up 900MiB of memory? Really, this is what I want? Hell no, i'll stick to what I have thank you very much.
Certain web developers are an interesting breed of late.
We live in an age of unparalleled abundance. "Evolution" no longer selects as aggressively against devs who are inefficient.
It still does - but now efficiency is measured in development/maintenance time.
If you want to see what's going on in WebKit, just check out https://webkit.org. A simple way to follow along is to read the "What's New In Safari Technology Preview ##" blog posts (and install the Safari Technology Preview to actually try this stuff out).
With iOS 1 lot of developers thought Apple was terrible for promoting web apps and that native should be the way forward. And so the app store and native apps arrived in iOS 2.
Now, apparently, Apple is terrible for having native apps and that web apps should be the way forward.
How things go in circles...
It sounded like they always expected to do native apps, just not nearly as fast.
https://jakearchibald.github.io/isserviceworkerready/
As I watch HN I see people talk about things that are 'missing' in Safari and they should be able to do from JS and many of them horrify me. I don't want random sites to know the light level of the room I'm in. I don't want them recording audio. Log running background tasks? Didn't we learn from TSRs? I don't trust random devs with that.
https://jakearchibald.github.io/isserviceworkerready/
My point being, this isn't new. Since interactive applications first happened in the browser, this has been the objective whether we like using these things or not.
Suppose the users aren't aware that your app is wasting their battery power, because of it's bad performance?
Suppose your users don't complain because ~90% of software is written slow, and so they expect sluggish response. Maybe you could be getting rave reviews about how responsive your app is. Example: saw recently a discussion on reddit where a guy did an Android app in rust, instead of the usual Java/Unity etc. People who tried it out all remarked "wow that was the fastest opening game I've ever clicked on!"
CPU designers have been doing amazing things with hardware, let us not waste it.
Until I got complaints from the network manager at my work because it seems that when you skip the video ads it continued to play them in the background and used up the very meager bandwidth we had at the time.
It's very easy for a simple accidental mistake to cause all sorts of issues while the app still feels "fast".
(I'm still kind of surprised/disappointed that got through app review).
Also, just because something is fast enough that people don't complain doesn't mean that it's fast enough that people are happy. I'm used to the speed of my TiVo, it could be MUCH faster.
The truth is: people are used to poorly designed things that don't go very fast. That doesn't make it OK to give them more of them.
Wow. People like this are why people hate JS devs.
If you don't need native functionality, or video capability, then mobile web is going to be a 1000x better choice.
Makes sense after all, its easier, faster, cheaper, less storage used etc... and more accessible to get to something on safari or chrome than publishing an apk or ipa
Now, the real question to me is where are people spending their time? Pretty much all in apps, but only for the top 10-20 apps in the marketplace - which means that unless you have a top 10 app that is going to pull people off of their FB/SNAP etc...app and onto yours, then don't waste your time.
[1]https://venturebeat.com/2015/09/25/wait-what-mobile-browser-...
> You get to utilize your existing JS, HTML, and CSS skillset to develop a single codebase that runs on both iOS and Android.
This always reminds me of the quote: consistency is the hobgoblin of small minds.
You see this "consistency" argument rear its ugly head all the time. I can remember hearing it when GWT was being pushed ("you can use your Java code on server and client"). The reality of course is far from idyllic. But that was completely predictable.
You also see this argument with Node.js.
The problem when you try and broaden something like this is it's incredibly difficult not to end up with something that doesn't simply combine the worst of both worlds.
Now I'm not an iOS/Android dev but from the sidelines I tangentially keep abreast of what's going on. It seems like React Native has some real potential here. Like some benchmarks I've seen show there's not much of a performance hit. If (and that's a big "if") this turns out to be the case, pulling this off would be a rare feat of success.
Now even if it succeeds, there'll still be a cost. I'm sure there are some things that are easier in iOS/ObjC/Swift and Android/Java. For one thing it would be difficult to abstract away the different memory management models (IMHO ref-counting rather than GC in iOS is a competitive advantage).
Anyway I don't think Apple killed Web apps or hybrid apps. Two things killed those:
1. HTML/CSS/JS is honestly horrible. Particularly layout in CSS (mainly pre-flexbox). Performance isn't great. People end up with Web apps with 1M+ DOM objects. That's just crazy.
2. Performance is just so much better on iOS/Android (rather than HTML5). Part of this is you know a lot more about the target platform than with a Web app.
> Make No Mistake, Going Hybrid Is The Right Choice For The Vast Majority Of Apps
I think that is very presumptuous. Maybe it is for some developers. I used Cordova sparingly a few years ago. Most of my hybrid development going back to 2012 is using Appcelerator Titanium. In fact, at this very moment I'm putting off working on a project built on the Appcelerator Platform, because of the giant headache that it has caused me.
Here are some of the reasons that I'm in favor of native development, with completely separate codebases for each platform, possibly using some shared libraries when appropriate.
1. As alluded to in the article, even with hybrid you have to put up with Apple BS. And it turns out, Xcode is not completely terrible; eg. in 2017, building a native app, you don't have to worry about provisioning profiles (much), because Xcode handles this for you. I was shocked when I discovered this after developing hybrid apps for years. If I have to learn it anyway, I might as well use it.
2. Quality/reliability/ease-of-use of third party libraries is higher. Yes, there are legions of Javascript developers out there, and some of them are trying to build mobile apps. There are also a great number of native developers out there and (trying not to ruffle too many feathers, and with no data to back this up) they are on average more experienced than the average javascript developer. They are also writing COMPLEX apps, and as a result we have a large ecosystem of good libraries that do a lot of the things that one might need to do when writing a mobile app, and they probably work out of the box with your toolchain, because the developer is using the same toolchain as you. Just drop it in, and use the API.
3. Hybrid app frameworks do not expose the full feature set of native platforms. Yes, Appcelerator just released "Hyperloop" to the masses which claims to do just that. I haven't tried it. Why make native calls through Appcelerator when I could just make native calls to the OS?
4. Hybrid app frameworks have their own bugs, and limitations that require strange workarounds. One might think that running into these would be uncommon. All it really takes is one, if you then have to sidetrack into learning about the codebase framework you are using, potentially rebuilding from source if there's no way to work around it at the top level. By the time you get it all sorted, you may as well have just done native. Sure Xcode has bugs and limitations too, and Appcelerator has definitely improved in this area over the last 5 years, but with layers of abstraction comes layers of new problems.
5. Technical support is easier to come by with native. Having a problem with something complicated? Good luck finding an existing question and answer of Stackoverflow. There just aren't enough knowledgable Javascript devs doing complex things with hybrid apps compared to native. Also, the hybrid app development ecosystem is fragmented: the problem you are having with Cordova is probably not the same as the problem I'm having with Appcelerator. Or maybe it is, but it's not readily apparent.
6. Native toolchains are superior to hybrid ones. I'm stepping out a little bit here. I abandoned Appcelerator Studio years ago in favor of the CLI, so I don't know what I'm missing there today. Well, I do know that I'm missing a decent debugger. Maybe that is in Appcelerator Studio - I have no idea. Feel free to call me out on this one.
In summary, hybrid is probably the right answer for SOME apps, and SOME developers. Based on 5 years of experience building hybrid apps, there are very few apps that I think wouldn't have been better (without consuming additional budget) as native apps. There are too many unknowns for ...
And recently, they've opened up 'Hyperloop' to the (now) free Indie Tier. Hyperloop allows direct access to native iOS and Android code, modules, pods, Frameworks, jars, aars, etc. right from within the Javascript code.
I used Angular a lot too and have built Ionic apps with that knowledge too. But, my overall opinion is that Titanium is by far the best. (As long as you pick a good stable SDK version! ;) )
Thanks god for Apple, I guess, then...
Imagine a headline like: "If it wasn't for Apple/MS, most of your desktop apps would be Electron based".
How would you like that?
Speaking from personal experience, the time it takes to create workarounds for UIWebView/WKWebView is only slightly less than the time to get familiar with Swift/UIKit. With knowledge of mobile paradigms it is easy to pick up Java/Android.
The advantages of creating two separate native apps are designs that fit each individual platform, better battery life, and overall better performance.
The author's time to market using hybrid development was less than the time it would've taken to learn iOS/Android native development and ship. However, the time difference is not as large as one may think. By continuing to invest in hybrid app development the author didn't learn valuable iOS/Android native app development skills and created an app that isn't as performant or designed to fit each platform.
I still develop hybrid apps for clients (glorified web pages, really) but for personal projects I will never, ever go back. Kicking myself for not learning Swift earlier.
So in other words, he spent less than 50% of the time needed to build both an iOS and Android app (if we assume learning Java and building the Android app will take equally as long as learning Swift and building the iOS one). Sounds like a huge win if one can live with the other tradeoffs.
...because neither "hybrid" nor "app" is an ambiguous term taken on its own.
Hey, look, here's some niche API, that few people are familiar with, but blame Apple about... something. Get mad about it!
I think Hybrid has it market and it makes sense for some apps, but for medium/big companies you probably end up with a native app (or a hybrid app with more native).If the app is native you can do more things in the device, there is better documentation for how to do complex things and you don't have to use Javascript. Swift and Kotlin are much better languages to use for apps. But I think the main point is that apps, nowadays, most of the logic of the app resides in the server, so the apps are only front ends. And to make a nice front end with smooth animations it is easier to do it native, because animations are different for every platform, so there is not much code to share.
Disclaimer: I've been writing and shipping iOS apps since shortly after the iOS SDK existed, and writing and shipping Android apps for the last couple of years. My opinions may be biased.
First, a couple of observations to get out of the way that may support author's thesis, but IMO not really:
- A good portion of existing native apps should not be apps at all. These are apps for services that are infrequently used, and should have been websites the entire time. Note that I'm saying they shouldn't be apps at all - native or hybrid - they should simply be websites. Because of the friction of installation, shipping an app for something users will only very occasionally use, is pointless.
- If your apps are strictly by-the-numbers CRUD apps without background activity, then a hybrid approach is likely the best bet.
Now that that's out of the way...
> "A Hybrid version of an app will never be as fast as a native version of the same app, but it doesn’t matter as long as the Hybrid version is fast enough."
This assumes the lack of competitors who are willing to put in the effort to make a performant app. It should be noted that janky, slow UIs that are "good enough" were the norm before the iPhone came around and raised everyone's expectations.
If you're building an app for Comcast or your local utility company - where competition is definitionally non-existent, then yes, it doesn't really matter as long as the hybrid version is fast enough.
For markets with competition, this simply produces a large window for someone to eat your lunch.
> "You get to utilize your existing JS, HTML, and CSS skillset to develop a single codebase that runs on both iOS and Android."
This seems user-hostile. For all of Apple's warts, one of the great things they did around the iPhone is to rebalance consumer software development away from developer convenience and towards user convenience.
The 90s and early 00s was defined by software that was difficult to use, engineered to be just "good enough", and largely the process was geared around developer ease rather than user satisfaction.
Yes, as devs we want all kinds of shortcuts to make our lives easier - and by all means we should pursue them - but the market in many places no longer tolerates the UX compromises of certain shortcuts, and consumers have come to expect apps to respect their platform's UX standards and have a high performance bar.
Case in point: Java apps also allowed devs to ship multi-platform from a single codebase, anybody here actually enjoy using those things? Practically nobody does that any more.
> "Viewing changes on your device during development is nearly instantaneous."
This is legitimately a great feature of web dev vs. native. There is a lot of work being done on iOS and Android to shorten the preview cycle - but it's nowhere near web-quick (and is unlikely to ever be).
But again, this is a developer convenience, not a user convenience, and like all developer conveniences, it should only be pursued without harm to user experience.
> "You can push updated JS, CSS, HTML, fonts, and images directly to all of your users without needing to recompile the app’s binary and getting App Store approval."
This is the part I wanted to touch on most: DO NOT DO THIS. This is explicitly against App Store TOS and can/will get your app rejected or pulled without notice.
You cannot ship features to the App Store without a binary update. This is also not a hypothetical - Apple has recently started ratcheting up enforcement on apps that significantly modify functionality while bypassing the review process.
If you want to build a hybrid app despite my objections, by all means, but do not use code push features and especially do not use it to bypass A...
> This is the part I wanted to touch on most: DO NOT DO THIS. This is explicitly against App Store TOS and can/will get your app rejected or pulled without notice.
I just came here to say the same thing.
I guess it's still useful in 'enterprise' scenarios though, where you are distributing apps to a restricted set of users by some other means, such as through Microsoft's Intune. I don't know why Ionic Deploy and CodePush don't make this plain though.
Edit: I just checked the CodePush FAQ, and they seem to be interpreting the Apple developer agreement such that updates outside of the app store are allowed as long as they don't radically change the app [1].
Personally, I'd be really wary of going down this path, worried that Apple or Google would pull the rug out from under it. Anyone here had any apps rejected or pulled for using CodePush, Ionic Deploy or something similar?
[1] https://microsoft.github.io/code-push/faq/index.html
Lest anyone forget, the iPhone's original "SDK" was web apps. People cried out for a native SDK.
Can't we point to this trend more generally being driven by Microsoft for years?
Or IBM before them?
This is a symptom of our economy as a whole. A big player dictates what is acceptable output. Not directly, but through a kind of market capture.
I get tired of these very specific, customized complaints about society, that ignore the bigger picture cause.
http://www.androidauthority.com/apple-iphone-average-selling...
I worked on a cross-platform mobile development tool called Nomad for Visual Studio (from Red Gate Software) for a while back in 2013, since retired. Back then hybrid mobile apps, for the most part, absolutely sucked balls in comparison with their native counterparts. Performance, in particular, was often choppy, and it largely wasn't possible to offer an anywhere near native user experience.
(I know, I know: everyone's going to point at Untappd, which was 2013's poster-child hybrid app, and talk about how awesome that was, but whilst it was decent, it was still noticeably hybrid. And, yes, there were and are companies selling native controls that can be used from a hybrid app to make things easier/better/more performant.)
The experience of working on Nomad taught me one thing: if you were serious about mobile app development, and you wanted to provide users with a great experience, your only option was to go native, be that on iOS or Android.
Four years has passed and, nowadays, the situation has improved quite a bit for hybrid apps. Still, it's disingenuous to suggest that most apps would be better as hybrid.
Sure, your app might run "fast enough" for many scenarios, and the user might not be able to even tell the difference between native and hybrid implementations, but if your hybrid version burns 10 times as many CPU cycles as its native equivalent would you're caning the battery life of the device, which is an aspect of mobile performance that seems to escape a lot of people. Speed is one thing, but how long you can continue to use the app or device also matters to people. (I say this as somebody seriously considering porting a couple of HTML5/JS games to mobile at some point in the future.)
This problem becomes particularly pronounced if you're building an app - and this goes far beyond games - with any kind of fancy media component, custom drawing, etc., any kind of rendering, doing anything cool/fancy with music or sound. You can take advantage of WebGL and shove a bunch of work onto the GPU, which will almost certainly do better battery-wise, but if you have some idea that you can just hack something cool and flashy together with HTML5, JavaScript, and CSS, and it won't drain the battery and make the device quite warm, you are likely to be disappointed.
I will agree that iOS is an absolute pain in the neck to develop for when it comes to doing anything remotely interesting with web technologies, regardless of whether that's as a hybrid app or even just in browser. But that's a long rant for another day.
Xcode and Instruments has some solid tools for monitoring this, but if he's a developer who refuses to learn Xcode anyway, he's not using these tools.