Hacker News Reader

I agree with PPK, but sorry to say this: you are just throwing garbage.

> There's nothing more annoying to a mobile user than an "app" that takes 10 seconds to start up

Try this on your mobile browser http://hn.premii.com/

Now download this. Android : https://play.google.com/store/apps/details?id=com.premii.hn Or iOS: https://itunes.apple.com/us/app/hacker-news-yc/id713733435

And play with it. Download top 5 native HN apps, and launch those, and tell me which one takes 10 seconds on which device.

No doubt that you will have to deal with different version of webkit browsers (webview) on android. As long as you follow standards and not use latest CSS rules, you will be fine. And with Android 5.0+, its much much better.

---

Now try this page on your mobile, and tell me how bad it is. This is few hours of work (Flipboard style animation), and works on iOS/Android Chrome/WP8: http://reddit.premii.com/#/r/news

There are issues with browsers, but performance is not one of the issue.

----

It takes time on Cordova not because of HTML, but because how each platform works natively. I am not a native developer.

I don't see the point of comparing HN apps. HN is a website and doesn't do anything meaningful as an app.

Android 5.x has less than 10% marketshare, and 4.x seems quite resilient in low-end devices. It's going to take a while until you can build hybrid apps exclusively for Lollipop.

If you don't think mobile browsers have performance issues, you must use high-end devices exclusively.

What is meaningful app?

Twitter is list of stories with notifications. For me its more like HN app. HN has list of stories, Twitter has 140 characters tweet. When you click on the HN story, you get list of comments or article. When you click on the tweet, you get replies and retweets and so on.

Facebook is a same thing with pictures and videos. Try this http://reddit.premii.com/#/r/pics - enable pictures view from top right dropdown and http://reddit.premii.com/#/r/gifs to try gify/video

---

I didn't start with Android 5.x. I started my app with Android 4.x. I don't think you use low end Android device. Even native apps on Android has lot of issues related to performance.

On my Nexus 5.0/Android 5.x, Facebook scroll is not smooth when there are pictures. I only get non-important notifications from my twitter app.

I test my app in first generation of iPad 2 (My iphone 4s broke) and galaxy s3.

---

Now show me 5 meaningful 100% native apps (Non-game) that are not developed my a startup with a huge capital or big company, available on iOS and Android, and has 4.x star ratings.

Well, lets see, I use Droidlight but that's by Motorola LLC, so maybe ColorLights. ConnectBot (ssh client). Barcode Scanner (I'm not actually sure if this qualifies as 100% native -- but I think it does). Open Camera. K9 (email - there are others, with different strength/use cases). ChatSecure.

Now, these are all Android apps, and few (if any) have iOS versions. But they all have iOS equivalents -- and I don't think most of them would've been as good, as non-native apps.

Note the absence of stuff that works well as a website, like facebook or twitter. For games, I think the choice between native/html should probably be governed by the answer to:"Is it as much fun as html/webview?". This is a good yardstick for other "apps" as well.

For eg hn, there's no need for an app, but of course hn is a pretty terrible web page. There are a number of easy fixes that would make it more usable, especially on small screens, but the maintainers don't care. And that's fine -- it's not accidentally bad, it's intentionally bad.

One could make a similar site that didn't break voting, threading, screenlayout on small screens quite easily. And it should probably be a web site.

One can make a "web app" to schedule meetings (see doodle.com) -- and one could augment that with something native[1]. Or one could make native apps like the ones mentioned above.

Could one make a web-rtc proxy for ssh and allow logging in to edit firewall rules via web browser? Absolutely. I'm not sure I'd want that though. Not as long as web browser security refuses to learn from office macros: unsigned js code, all or nothing execution etc.

There is some middleground, as google docs demonstrates. Personally I prefer content creation/editing to be local, possible to do off-line (with sync) -- and I'd like competing apps to be able to easily share data (via eg: the file system).

Now, that twitter can't be bothered to make a decent web-site isn't really an argument against web-sites. It's an argument against poor web-sites.

[1] http://9to5mac.com/2015/05/14/sunrise-meet-keyboard/

> Android 5.x has less than 10% marketshare, and 4.x seems quite resilient in low-end devices.

Folks were saying the same exact thing about 2.x when 4.x came out. By the time 6.x comes out, everyone will be yammering on about how 5.x marketshare is still strong and "seems quite resilient in low-end devices", blissfully ignoring the point in time when 4.x - like 2.x - fades out of view as it's increasingly ignored by app developers.

Meanwhile, in the actual low-end space, you have things like FirefoxOS where there's zero difference between "web" and "native" because "native" apps are just web apps with special hooks for things like cameras and sensors, or you have things like "feature" phones where the closest thing to a standardized platform you have is Java ME.

In the real world, Firefox OS has zero marketshare at the low-end. Mozilla announced just a day or two ago that they're abandoning the low-end strategy.

Featurephones are largely gone. Microsoft bought Nokia's featurephone business, shut down further development and has been converting it to low-end Lumias as fast as they can, but Android is nibbling away most of that market.

Mozilla only announced that they're abandoning efforts to build the lowest-end stuff. IIRC, most FirefoxOS handsets are still pretty low-end, and have been doing reasonably well.

And feature phones are still dominant in places like Africa and South America, particularly due to their lower cost and power consumption (smartphones are still unable to reach the battery lives of even dumbphones from a decade ago, which is an important consideration in environments with limited/inconsistent electricity). Even in "developed" countries, feature phones are popular with the elderly and disabled, since they usually feature physical buttons that are easier to work with (better tactile feedback, easier to find with poor vision, etc.) and have simpler interfaces.

As a user of Android HN apps, premii seems to beat them in all aspects. The major aspect being them actually working properly.

It seems like apps are less maintainable. Right now pretty much all of the Android HN apps are broken in some way, or missing a core feature of the desktop experience.

App requires more work to maintain. its much easier to update website. App requires a build, submission, approval etc.

I have not updated my downloaded app in long time.

For HN, official APIs are very limited.

Premii is a great example of spending a great deal of effort to fuck up basic native behaviour like scrolling. The inertia is completely wrong.

Both Android Studio and XCode will give you usable iOS and Android code from visual layouts. I've found that usually the easiest way to prototype an interface is just to build it for real - it's faster than Photoshop, even.

The hard part about X-platform mobile development is that oftentimes you need different product concepts on Android & iOS, because the idioms, best practices, device capabilities, and user expectations are different on each platform. So your client generally has to be ground-up development by an experienced expert in the platform, you can't just take the same layout and make it run on both.

Both Android Studio and XCode will give you usable iOS and Android code from visual layouts.

Well, for some definitions of "usable" and "visual layouts"!

Our goal is to make a designer's tool that can output complete, store-ready projects for simple apps and for both platforms. That includes three things that neither Xcode nor Android Studio does:

1) Interface Builder and Android Studio's layout editor are not meant for designers. (Seriously, try giving them to a Photoshop-educated designer.)

2) Xcode and Android Studio let you define views, but neither of them produces the controller-level code from visual designs. (We do that and also produce model-level code for simple apps; there's a plugin API for more complex situations, or you can of course do that in handwritten code.)

3) Cross-platform. Anything you do in Xcode or Android Studio needs to be rebuilt from scratch on the other platform.

...the idioms, best practices, device capabilities, and user expectations are different on each platform.

I feel that this doesn't hold true anymore. iOS 7+ and Android 4+ have largely converged on a flat style where a 3rd party app can define its own style that is easily compatible with both.

With Windows 10, even Microsoft is coming into this "common mobile" UI fold. They're giving up on the idiosyncratic (and interesting) Windows Phone concepts, and instead adopting a generic look that makes it easier to port Android/iOS apps directly. They're also offering new APIs and runtimes for that.

(Edit: To clarify, you can customize layouts separately for iOS and Android in Neonto Studio.)

I'm sorry, after reading you say "they are now the same because they are flat", I sincerely hope you fail. You are clearly not a designer, yet attempt to market a development tool as such.

It's just an observation: for real-world apps, iOS and Android visual styles and conventions are growing closer rather than diverging (and Windows 10 is trying hard to fit into the same mold).

For a random example, look at Periscope's new Android version -- the differences from the iOS version are minor, yet it fits in nicely on Lollipop: http://www.theverge.com/2015/5/26/8657349/periscope-android-...

As for the "I sincerely hope you fail" part: we're a startup, so we're likely going to fail anyway. Thanks for the honest sentiment, I guess.

Your observation about iOS vs Android is very narrow-minded, either deliberate or inadvertent. There are profound design language differences between iOS and Android material design. Claiming "flatness" is very shortsighted indeed.

A word on Windows 10, mobile or otherwise. It is indeed a mess, with almost no coherent design language, something that Phone 7, Phone 8 and Windows 8 actually had, for better or worse. Windows 10 throws many of the good design choices for a faux Android look, and a very bad one at that due to complete lack of consistency. Android also lacks consistency throughout, but at least a somewhat coherent design language exists now.

I do not wish to argue here. Do not take my wishes personally. As someone who wishes to only see good technology succeed, and I do not see this as good technology. I do not wish personal failure to anyone individual, and wish you personally all the best.

That's missing the point of what makes a good app. It like you say about Cordova apps: the last 20% takes 80% of the time.

Notifications are completely different on iOS and Android. Sharing data between apps is completely different. Wearables are different. Communicating with a server is different. Accessing contacts is different, as is accessing the camera. Sensors are different, and often differ between Android models.

Most of the big mobile success stories we've seen in the past 5 years have come from people utilizing the unique features of the phone, not treating it like a 5-inch dumb terminal.

"With all that, the last 20% of a Cordova app may well take 80% of development time, and that's rarely been budgeted in."

To be fair, that could be said about most software projects. "80% done, now the last 80% remains."

Not that I disagree with you, I had the same experience trying to make an Android app in Phonegap. It's lacking, like most cross-platform frameworks (for most types of apps, but typically not games) I have tried. They are only suitable for basic stuff where the native feel isn't critical.

To be fair, that could be said about most software projects.

Yes, absolutely true. The difference here is between "known unknowns" and "unknown unknowns", to paraphrase a certain renowned military strategist...

With Cordova/PhoneGap, it's easy to get the initial impression that you're dealing with "known unknowns", just the typical web development project pitfalls -- "This is HTML, I know this stuff".

When the "unknown unknowns" hit the fan, it's often pretty late in the development cycle, and so things blow past original estimates even though they were competently planned. It's just that the plan was for web development, not the shifting art of websites-in-drag-pretending-to-be-apps-development.

I agree with that. With an abstraction layer on top of a native layer, inevitably you have to go below the surface unless you fit the intended use case perfectly. I learned this lesson with the Objective C-Python bridge. Spent needless time mapping differences between the two to the point where I had to learn Objective C anyway.

I agree, but one minor nit: when major problems crop up "pretty late in the development cycle", this typically means a waterfall development cycle.

Waterfall approaches are really only appropriate when there's nothing particularly risky. I plead with the HN audience: never let a manager choose the waterfall model by default. They often happen because they make contract negotiation easy. But that's only because they save all the trouble for later.

side comment: the rule is called the 90-90 rule [https://en.wikipedia.org/wiki/Ninety-ninety_rule]

What do people think of frameworks like https://jquerymobile.com and similar?

I tend to think it's good when running in a browser but not when it's made mobile web app capable and running full screen without native controls. Unless it's a super simple single page app.

At the other end there are things like Instagram where you basically can't do anything on the website (can't sign-up, can't upload photos). Everything requires the app.

I absolutely hate jquerymobile, you should just make your website responsive with CSS media queries then pepper in a little bit of javascript to handle things like slide out navigations.

I read that Appcelerator Titanium and NativeScript are a much better way.

You can use much of your JavaScript skills and still get to go native.

Unless that platform has changed completely in the last year or so then they are wrong. Appcelerator (and things like it) generally make "Hello World" super easy and even the first week or two will be awesome. Then the cracks will start to show. You will add a listener on a button and the app starts crashing with a cryptic error, you start having to litter your code with `if(isAndroid)`/`if(isIOS)`, or for some reason a view will be really show to render to lag between clicking and doing something. When you get down to it you'd be better off learning native or just accepting a mobile website instead. Normally (IMHO) the only apps worth using appcelerator for are simple websites and at that point you'd be better off just doing a mobile website.

I'm excited to play with React Native but I fear it will suffer from the same issues.

I agree with most of what you say, but:

you start having to litter your code with `if(isAndroid)`/`if(isIOS)`

That's an inevitable drawback of a cross-platform framework like this. XCode and Android Studio only work with one OS, so they sidestep it.

Sidestepping a problem in universal app development by don't doing it.

You're joking right? ;)

> For developers, Cordova/PhoneGap-style tools are not a panacea either. It's easy to get an 80% solution done, but then you run into problems with mobile browser performance.

That is a thing of the past. At the current rate of smartphone/phablet specs growth the differences with desktop are laughable (you can currently get 64bit octacore@1.7Ghz mobile devices with 3Gb of RAM for around $100) [0]. And this will only continue to grow. 16core and 32cores will be here in 2-3 years [1].

IMO, hybrid apps are already the present. The difficult times when we didn't have the required performance in our pockets are long gone... and frameworks like Ionic are really convenient for certain use cases.

> browser differences between devices (even Android devices with the same base OS can have very different web view browser engines)

That has been already solved with xwalk [2]... but again, this will be irrelevant in a couple of years.

[0] http://www.gearbest.com/cell-phones/pp_152602.html

[1] http://www.xbitlabs.com/news/cpu/display/20130304235830_Pres...

[2] https://crosswalk-project.org/

the amount of cores makes no difference when javascript is single threaded. Infact its often detrimental especially on mobile because each individual core is significantly weaker.

Plenty of websites doing advanced html5 gunk bring top of the line systems to their knees.

Ok, valid point... But still the Ghz's per core are also increasing, and with that the overall performance. If you've used webapps like Popcorn-time or Slack you'll understand what I'm trying to say.

Are they native? No, they're JS apps

Do the users care? No, cos they do the "job" pretty well

We're reaching that computing power with mobile devices. In fact current mobiles are like desktops of 3/4 years ago. For certain kind of apps it won't matter if they're built with web technologies. (I'm not saying that you should bet on WebGL vs OpenGLES)

It's all about the use case.