Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


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.


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: