Live data from Hacker News

Framework 7 – Building native iOS apps in HTML5

idangero.us

71–80 of 131 posts

Re: Framework 7 – Building native iOS apps in HTML5

#71
post #69
post #30

Earlier quoted context omitted.

> First, you have the absolute most control you will ever have over your application. You have 0 control over distribution though, which is pretty important to me. > There are some amazing libraries for both platforms that you definitely don't want to miss. I don't doubt that the platforms have good 3rd party support, but it's absolutely dwarfed by that of the web community, and that will only grow larger over time.

> You have 0 control over distribution though, which is pretty important to me. Simply having to wait a week to get approved for the iOS App Store (and less on Android) doesn't constitute 0 control over distribution. You can still release the app to the store when you want, if you plan ahead, and pull it whenever you like. Less control, yes, but not zero. Also, how is this different from writing a non-native app? The…

> Simply having to wait a week to get approved for the iOS App Store (and less on Android) doesn't constitute 0 control over distribution. You can still release the app to the store when you want, if you plan ahead, and pull it whenever you like. Less control, yes, but not zero.

You don't have control whether your app will be accepted into the store (like the recent bitcoin apps), you don't have control whether the content in your app will be allowed in the store (such as the many Comixology comics that where banned from being sold).

> Also, how is this different from writing a non-native app? The same rules apply to distributing web apps if you want them to be in the store.

But I don't have to put my web apps in the store at all, I just tell my users to visit a URL.

Re: Framework 7 – Building native iOS apps in HTML5

#72
post #64

I'm baffled that a technology stack (HTML, JS) that every single web developer think is broken (but still have to deal with) is being considered for iOS development, and being promoted as an easy way to develop native apps. This is where I think RubyMotion offered the best of both worlds: native APIs and Ruby's flexibility (even if Objective-C is really not that bad or hard to learn).

Web Dev here. I don't think the stack is broken.

Re: Framework 7 – Building native iOS apps in HTML5

#73

Earlier quoted context omitted.

I don't buy it. Enterprises definitely buy into that idea and they do have their employees work with these crippled apps because they have no other choice. But the experience for this 'CRUD' app is definitely not good enough. It's by forcing it that it gets used. It depends on how intensively it will be used in reality, but I definitely know quite a few companies who went from BYOD and an HTML5 Cordova app which was…

You don't have to buy it, it's an undeniable reality. Yes, if you're an enterprise and you can afford to write native apps for all platforms, then that's the better choice. If you're a small startup or a single developer, writing the app 3 times is just not cost effective.

Well then there are still a few options; 1) it's internal and you can force-feed it to your employees, then it might be ok 2) it's external and you're trying to get a lot of people to work with it outside your company.

In both cases I still think you are better/easier/happier/cheaper off building it once and in case 1) giving your employees tablets/phones with the target OS and in case 2) just waiting till you have enough critical mass to warrant writing a version for the next OS.

Not to mention that, in most cases we have made HTML5 'hybrid' apps, we noticed that it takes more time making it uniform and smooth across the plethora of (especially Android) devices than just writing 2 native versions. And the HTML5 version will just never work well on a large amount of 'Alibaba $50' Android devices which surprisingly many people have. Resulting in TONS of bad reviews (if public) and/or very frustrated people.

Re: Framework 7 – Building native iOS apps in HTML5

#74
Cross-platform UI is a bad idea on the desktop. Cross-platform UI also is a bad idea on mobile. We need to learn from the past. Cross-platform UI is a conceptual mistake. An app that has an icon on the home screen is perceived by the user as "an app", no matter if it actually launches the browser without the toolbar, if it is a web app wrapped in a PhoneGap shell of if it is a native app. To the user, it's an app. It has an icon, so it's an app. The rest are implementation details that the user doesn't (and shouldn't) care about. So if the user perceives it to be a native app like all the other apps, it has to behave like one. Otherwise the user will be disappointed. Web apps that mimic native apps simply don't behave exactly like native apps: Imitating native UI with web technologies on a mobile device will only disappoint.

Re: Framework 7 – Building native iOS apps in HTML5

#75

Cross-platform UI is a bad idea on the desktop. Cross-platform UI also is a bad idea on mobile. We need to learn from the past. Cross-platform UI is a conceptual mistake. An app that has an icon on the home screen is perceived by the user as "an app", no matter if it actually launches the browser without the toolbar, if it is a web app wrapped in a PhoneGap shell of if it is a native app. To the user, it's an app. It…

As someone who spent years building "HTML5" JS mobile apps and then recently spending the time to learn native languages, I 100% agree. There is no way to match the performance and consistency of native with a cross-platform clone. It will always be a half-baked solution.

That being said this only applies to apps. A ton of apps shouldn't be apps, they should be well-optimized websites. For ex. content sites.

Side Note: Learning Objective-c and Android java dev isn't nearly as bad as I thought it would be. It takes less time to learn and build native instead of trying to hammer Javascript into a hole it doesnt fit into, and spending hours attempting to optimize it's performance to no end.

Re: Framework 7 – Building native iOS apps in HTML5

#76

The limit we've run into with iOS is not getting a good looking UI. Rather it's the performance of Javascript in Safari. We have a fairly large one page webapp that looks great on iOS however the performance is an order of magnitude slower on an iPad than Chrome on an old laptop.

Can I see it?

Sorry but we're limiting public access while we work out some issues. There will definitely be a Show HN when its ready for public viewing.

Re: Framework 7 – Building native iOS apps in HTML5

#77

Cross-platform UI is a bad idea on the desktop. Cross-platform UI also is a bad idea on mobile. We need to learn from the past. Cross-platform UI is a conceptual mistake. An app that has an icon on the home screen is perceived by the user as "an app", no matter if it actually launches the browser without the toolbar, if it is a web app wrapped in a PhoneGap shell of if it is a native app. To the user, it's an app. It…

A long time ago when iOS dev tools were immature Joe Hewitt created https://github.com/facebook/three20. I can't find the source, but somewhere Joe is quoted that so many of the early Facebook application reviews were about how so much of it was derivative.

There is absolutely a place for this kind of library and if you pay enough attention to the details (sweat every pixel and animation) I fully believe that you can achieve an experience that would be completely indistinguishable from iOS.

Notes:

1. For this to work you should be using something like Ember as your front-end framework, not jQuery Mobile.

2. I'm not pushing this as dogma, I'm just very glad that it exists within the ecosystem.

Re: Framework 7 – Building native iOS apps in HTML5

#78
post #14

I'm not knocking this or any particular xxxx-to-mobile platform, but as a native iOS and android developer, I would highly recommend just learning the native languages and frameworks. First, you have the absolute most control you will ever have over your application. This may not be true when a particular tool becomes popular, say at the release of a new tool, but this definitely shows up as time progresses. Who know…

So if you want a web app, an android app, and an iPhone app, you have to code it up 3 different times in three different languages. The reason why the web exploded in popularity as a development target is precisely because it made it easier to target a larger number of customers. Imagine if Facebook had started out as a Windows XP / Linux / OSX native application. It never would have even got off the ground. My take…

You are forgetting about the modern contender - Xamarin. It's a sweet spot between HTML5 and native: modern high-level language and a very decent performance.

Re: Framework 7 – Building native iOS apps in HTML5

#79

Earlier quoted context omitted.

"security reasons" (= http://bit.ly/1d7p5Tq ) it would be interesting if they elaborate on those...

My understanding is that you would have to mark some of the apps pages as executable, iirc, which could allow for arbitrary code execution.

That makes little to no sense.

This reeks of the same logic that caused them to disable HTML file upload buttons (there's "no" filesystem -- which is apparently why you can't even browse for photos and uploads until recent IOS).

This is what drove "there's an app for that" for so many years: Apple's systematic limiting of web apps into a severely curtailed walled garden so that the app store would -- in fact, could -- be the only source for real applications.

"Web Apps aren't as performant as native" is a direct result of such strategies.

In other words, those strategies WORKED. As with all anti-competitive practices, they will keep doing their job for a while, until something new and better (or at least workable) comes along.

Re: Framework 7 – Building native iOS apps in HTML5

#80
post #15

Native apps in HTML5 is an oxymoron.

The only native apps in HTML5 are probably some of those Win 8 apps. If you think about it HTML5 is just a quirky version of XAML and the latter is supported in Win8 very well. Maybe OS itself should give a choice of layout engine.
Post reply on HN