Hacker News Reader

"The actual MAS store app itself is a horrible piece of garbage wrapping a bunch of web views. Just make it a real native app and rewrite it."

Native app is not really a black and white concept when you're talking about an app that mainly just interprets and displays live data it receives. If it's not html, then it's going to be xml/json/some other markup with a custom presentation layer on top. Why would that be better? In this case I just don't think you can point the finger at webview vs native as a problem or a solution. Yes, the app may be crap, but that seems mostly unrelated to the technology used to build it. I'm guessing it's more a factor of lack of resources, team member quality, management, or inter-departmental communication issues in a large corporation.

You're probably right. I would still agree with the parent in that they feel like a badly done webview wrapper, because the symptoms are so similar.

iTunes Store, App Store, MAS, Apple Music — there is definitely a pattern there, at least on the desktop. I find them all similarly clunky, slow, ugly and unpleasant to use.

Apple almost seems to be inherently incapable of creating a decent store front, and I am curious as to why they have that organizational blindspot.

> Apple almost seems to be inherently incapable of creating a decent store front, and I am curious as to why they have that organizational blindspot.

Because when you have a captured userbase, there's no incentive to improve / innovate?

Even if you believe that Apple as a whole doesn't have the drive to make stuff as good as they can (fair, although I believe otherwise), and even if you believe they have a captured audience (how?) — do you indeed believe that Apple is happy with 15% (US) market share for desktops and laptops?

Even accepting everything else, that seems like a huge incentive to me not to get complacent.

> do you indeed believe that Apple is happy with 15% (US) market share for desktops and laptops?

Seeing as in 2009 they had >90% of the market of PC's above $1000 (see here: http://betanews.com/2009/07/22/apple-has-91-of-market-for-1-... ) which is the profitable part of the market, probably they are.

Not sure where you're getting 15% from: the vast majority of articles I read have Apple's app stores generating far more revenue than the competition's.

So yes, I believe Apple is probably perfectly happy (in an upper-echelon corporate strategy sense) sitting on their cash cow as opposed to fighting it out for less profitable market share.

The number is from Gartner for Q3 this year - for whatever they are worth :)

http://www.gartner.com/newsroom/id/3146617

"do you indeed believe that Apple is happy with 15% (US) market share for desktops and laptops?"

If that other 85% is cheap laptops with no margin in them, yes.

Apple has had the largest market share in mobile revenue, yet iOS keeps improving.

Most of the most visible features and improvements I've seen in iOS over the years were developed by the jailbreaking community and eventually apple incorporated into iOS.

Care to actually list that? I find that incredibly hard to believe. While there may be a list of 5-10 features that meet the criteria, seems like most OS releases have hundreds of improvements here & there.

All of Apple is just sitting around waiting for jail breakers to innovate for them, no one has any ideas about what to do with their time.

Don't even get me started on hardware! Incorporating all that stuff Samsung & Dell or whoever is doing.

Well Control Center came from SBSettings, for one. On a 3GS running iOS4, you could quick reply to texts, play background music, have a visual multitasking interface, etc.

This was years before iOS 7. Though most of the concepts seem to be taken from Android, which took most of the ideas from defunct WebOS. Well, mostly Apple and Google hired former Palm guys for their design teams.

The pattern is because they're the exact same app. All of those are just the iTunes Store, which is a web page on every platform. The iTunes Store is a little clunky but it works fine.

Apple also have the Apple Store, which is a separate thing that's a website - I believe it's a WebObjects app and the iTunes Store is as well.

> Apple also have the Apple Store, which is a separate thing that's a website - I believe it's a WebObjects app and the iTunes Store is as well.

This might have changed since they rolled the store into the main apple.com site, but as far as I know none of that is public for sure.

They did roll it into the main site, yeah, but I'd be surprised if it's actually a different app now.

The saddest part about this is that using WebViews really doesn't have to mean that it's clunky and slow. Slack's interface is pure HTML, CSS and JavaScript and it works just fine.

>creating a decent store front

Because when looking at the metrics they care about (see: $) they see a runaway success, and dismiss the idea that it isn't already "decent".

I don't think that most web developers looking for a job think 'Apple'. Google and Facebook would likely be their top pick and not surprising since both of those companies are far more web centric - Apple has historically not been so.

It's almost a chicken and egg situation where unless Apple builds top tier web apps they won't attract top tier web devs. Without top tier web devs they of course will struggle to build scalable, fast and user friendly web apps.

I'd imagine inertia also plays a role. Apple clearly have a lot of talent who know Cocoa and Obj-C inside and out. Chances are their current devs prioritise those kinds of apps over the kinds you might see Google or FB prioritise. Heck look at how long it took FB to come out with a decent iOS app. Their first mobile version was HTML with a native wrapper. It took FB time to build the talent base to do a decent app (believe they even had to hire Loren Brichter to consult to help them with it!).

Every company has its specialities. Apple is getting better but as their data loss issues with Photos and Apple Music, as well as their problems with MobileMe show they are clearly finding it hard getting web devs who can build what they need fast enough. It'll take them time - they have enough cash to get there but they sure are alienating a lot of users and devs with these issues.

xml/json as uses now is data transfer format, not some UI markup. As for why would it be better — because Cocoa is light years ahead in UI libraries and optimizations compared to web mess.

The app store has never felt slower than native apps for me. Instagram also seems to do pretty well.

Instagram is a native app.

Instagram's UI is made in HTML.

Its also very slow and whole UI is extremely buggy. Buttons would often be in improper state, download would start very slow, sometimes progress bar wouldn't show up even though download is happening. Resume would fail, caching would fail and almost nothing would give you any reasonable error message or something to solve the problem.

It;s probably the buggiest piece of software I have ever had to use. The backend service might be good (or not) but the basic store app feels like something written by an student.

I agree with you on almost everything beside the web view part. In my understanding web view is used because it's a very advanced layout engine and way easier and more flexible to deal with than to set all this up using the native layout engine.

Edit: For clarity.

Is it supposed to be a joke/sarcasm?

No but perhaps I wasn't being clear what I meant sorry.

What I mean is that using web view make it way easier to layout out networked assets. At least thats my experience having worked with both.

You had some reaaaaally reallly weird experience then. I don't even understand what you mean by "laying out networked assets". With proper architecture your UI won't even know where assets come from.

What I mean is that laying out using xcode isn't as easy as using a web view for the kind of layout that are needed for something like the app store.

Not sure why this is such a crazy thing to say that I need to be down voted for it.

100% with you. I love AppKit, but the amount of code required to make a simple custom button is insane. What is 5 seconds of CSS takes a good 30 minutes of wrangling with NSButton/NSButtonCell. The very existence of PaintCode is an indictment.

It doesn't make sense to say that WebViews aren't "native". With a little effort they can be made to blend in perfectly. It's the same CoreGraphics.

I think that’s countered a bit by less of a need for custom widgets. In fact I’d argue that one of the big points of appeal for native Mac apps is that they eschew tons of custom widgets in favor of the standard system kit whenever possible.

There’s also a good deal of power that you gain when writing custom Cocoa widgets; drawing is usually done with Core Graphics, which is a blazing fast, extremely capable C API. There’s a lot you can do in custom Cocoa widgets that would be impractical or dog slow with HTML+CSS+JS.

EDIT: Also, one big, big difference between WebView apps and AppKit apps is that while WebView apps might get their appearance reasonably close to native, they almost always miss the mark entirely when it comes to widget behavior.

Yes but the context is the mac app store which is much more a web-layout than a native app layout.

That's the problem, yes.

> What is 5 seconds of CSS takes a good 30 minutes of wrangling with NSButton/NSButtonCell. The very existence of PaintCode is an indictment.

Imperative graphics and view hierarchies certainly make simple things tedious, but they'll never match the DOM's ability to occasionally make simple things nigh-impossible either.

I'm curious, if you call drawRect ugly then what do you call the menagerie of frameworks required to strong-arm the declarative environment of the web into the simplest of desktop tasks (shadow DOM, anyone?) Pot, kettle?

> With a little effort they can be made to blend in perfectly.

I'll believe it when I see it. I'll grant you that this works OK on windows, but that's due to MS making the decision to bring the widget kit down to web-level rather than the other way around. Meanwhile, iTunes and the AppStore continue the long and well-established tradition of poor integration.

> It's the same CoreGraphics.

Hidden behind a dozen trendy frameworks, a hundred bloated abstractions, and a thousand crusty layout engine implementation details to glue it all together.

The context is layout not logic. There is a world of difference between the flexibility and portability of web formatting and desktop formatting.

Apps like Uber, Instagram and others use the hybrid approach.

WebView can work, but with no loading meters or error displays it's very painful. If a third-party developer released an app using WebViews the way Apple does, they would get a ton of complaints.

Sure I am not saying their implementation is good, just that the reason why they use it is most probably because it's much less painful to layout.

The layout in iTunes and the Mac App store app is something that you can implement with a native constraints based layout.

Yes but is it as easy to do? For all it's shortcomings very few things are as flexible and powerfull as being able to use web technologies to layout.

If you know what you're doing(which Apple should since they created the constraint system), then it's not that hard especially with the current constraint structure. There really isn't any technical reason why they shouldn't be able to reimplement iTunes natively and use backend API's to just serve content.

I don't think it's as easy as you think.

Having played around with apples layout and general UI related stuff myself quite a lot I can tell you that it's a lot harder than webviews. We are talking perhaps 50X for the kind of stuff like the App store.

  > I don't think it's as easy as you think.

I've been developing iOS and Mac apps for 8 years so my response is based on that experience.

Yeah. So don't know how much web you have done. But in my experience and many others i know who have done both. It really is much harder than web.

  > So don't know how much web you have done.

I've been developing websites since 1998.

OK then I guess we just have to very different experiences of doing layout :)

Apple totally has the resources to make a great native app experience, even if it's much more tedious. I don't see why they don't go the extra mile, especially since the app store generates so much revenue...

This is not a question of ability but what is gained from making it native vs. hybrid. You don't gain anything from using the native layout model that can't be done via web view.

There is no doubt the App Store is horribly done, but for the kind of content that is going to be in the store I simply don't see why they would choose otherwise.

Keep in mind that the apps also exist on the web. This would force apple to still make a web version and a native version.

Don't see what is gained from this.

* There's also the 30% cut, which makes no sense when you're talking about a well-known and well-trusted app like Sketch. Nobody fears installing Sketch outside of the MAS, so BC may as well host it themselves. I imagine the average new Sketch user discovers the app via recommendation, or article on the web, so BC will likely make more money away from the MAS. Especially when you factor in the improvements: faster bugfixes, and new features they can without sand-boxing.

Also for software more expensive than about $10, a trial is a must, and the Mac App Store doesn't allow for trials. So the user will seek out the trial version on their website, and then why even bother with the App Store?

I think the reason it feels so sluggish is that the servers it pulls data from take so long to respond. I don't think a native view would help with that, but it's absolutely something they need to fix.

Agreed. The iTunes Store has always felt extremely slow to me, even back in the day when it was implemented as native views.

> Have a "Power User / Developer Tools" category and associated checkbox in iTC that says "My app needs to opt-out of these parts of sandboxing". Put those apps through a much more strenuous review process.

I disagree with this. I like the sandbox constraint; i don't mind opting out of the app store if my needs necessitate dropping the sandbox. I also think the interface of the app store is the least of its concerns.

Everything else you said is on fleek.

By Apple's own analogy, Macs are "trucks". So why cater to the non-power users when you know (by virtue of the fact that your other platform is strictly sandboxed) that practically all your power users are on the Mac?

Strict sandboxing is not a good fit for the Mac.

No, I think power users are not a good fit for the apple store. I don't see a huge problem with downloading signed code from another site.