zw

This is a mind-boggling level of FUD. Content blockers have been noticeably superior on both macOS and iOS for years. They’re not “limited”, they’re rational. It’s abjectly absurd that traditional ad blockers can consume as much CPU as they do on every single page load. I hope everyone in this thread jumping ship to Firefox in a panic enjoys their shorter battery life.

And then maintained it and fostered its growth while it became the foundation of modern computing…?

I think it's gotta come from the other direction, ultimately. They're working hard to push AppKit forward and bring it into the future, but I think UIKit will figure out the hard problems (menuing, keyboard navigation, pointer input) before that.

I think pointing at Microsoft as having the solution to this problem is disingenuous. Modern Windows has had so many false starts, and I still feel their multi-modal devices are inherently compromised — jack of all trades, master of none.

"Native" being a really relative word here.

[Really easy to enable.](http://internals.exposed/blog/dtrace-vs-sip.html)

But, hey, sure. Don't let that stop you from getting angry. Merry Christmas.

There should be a bingo card for this thread. "#doomed" "taking away freedoms". Free space is "What Steve would've done".

It seems like they do that on OS X as well.

Based on the warnings in the Console log back when I used Dropbox, Dropbox isn't using fsevents API appropriately but is instead reading from the raw fsevents firehose.

I have nothing to say about your other issues (I haven't experienced most of them; I'm quite happy with the service), but the banner at the top of the More (…) menu takes you to the album of a song, which then easily leads to the Artist page. Do it all the time, takes me half a second.

Forget the "-ish". Actually, forget the "native". Their app is no more or less native than Rdio's was.

Not anymore; those methods are implemented in an extension on `String` that don't always involve bridging back.

Because you're making mistakes in those other languages? Because the world is not just English anymore, and "going through an i18n library" is all well and good until you need to accept literally any form of user input, which is kind of the point of programming.

> No default indexOf, length, and substring methods?

This makes me think you didn't read the post. There is no lack of those methods. There isn't a one size fits all version, because the problem space isn't generalizable.

But the definition of "character" is not generalized, therefore the use case cannot be generalized.

> obsesses a lot about not breaking backwards compatibility

Lo, how times have changed. ;-)

iTunes on Windows is as much AppKit as it is on OS X; which might be to say, not much, maybe… but definitely a lot of ObjC and Foundation.

`WKWebView` has issues that made it untenable for use as a web browser last year, but there's nothing I'm aware of preventing its use for common in-app browsers.

The Swift standard library is not yet up to snuff for that, you still need to know Cocoa to do basically anything high-level. Thankfully I know Foundation better than I do straight-up POSIX, so that's tenable for me, but it's not for most people who want something script-y.

Trials and upgrades are niceties for the developer, not the user. The App Store isn't made for developers, it's made for users. If developers want access to those users, they should build businesses not oriented around extorting money to fix their technical debt.

His Snow Leopard review was also in part a classic because the release was a classic. Nothing was left unturned in that OS, it was a goldmine for a guy like him.

I hope a feature release will be of a similar caliber (i.e., "make ALL the things better") and I hope Siracusa is strong enough to stay away from it.

For something that foundational, you have to move as one giant, lumbering beast. Recall that Apple had at least one (that we know of) false start. A fair bit of the OS (CoreServices; Carbon, and the apps that still rely on it) still relies on HFS+-specific data structures and features.

Core Storage is already moving forward as an effort to dissociate the bytes in logical storage from the bits on physical media. In the short term, we might be able to sandbox the evils of HFS+ by having it just be a software abstraction on top of a much more modern file-system-like-thing. Yosemite already moves any machine it upgrades to Core Storage, even if you don't use FileVault.

If I remember correctly from an article many years ago, they want the C++ API to be high-level and fast-moving; the C API exists so that they can support low-level use and almost all clients while only maintaining one API well.

It's [Windows Installer](http://en.wikipedia.org/wiki/List_of_Microsoft_codenames).

As someone who has used it extensively, Auto Layout is not a cause for performance UI regressions. Not by a long shot.

The Finder and all its functionality was ported to Cocoa in 10.6. All related functionality has eventually made its way into Cocoa: NSWorkspace, NSURL, NSFileManager, and NSFileCoordinator. The Carbon file management APIs are long, and thankfully, dead.

No, iOS has had tools for building apps with flexible canvases, that has very little to do with the resolution of the screen these days.

2009! They thought they could get it done in time for Snow Leopard GM!

Thrilled to see FastMail tastefully and respectfully grow their ecosystem. I can see that, at least for the iOS app, it's pretty much a web view wrapper; I'm willing to give it a pass for the most part because FastMail's webapp is one of the best I've used… ever.

Even still, as a green-fields iOS app, I'd expect to see a little more in the way of embracing features that are now native. We have notification actions, extensibility, file sharing, and a Pebble SDK too, y'know.

Still, keep up the good work! You'll have my dollars as long as you're not Gmail.

Yeah, they sell off-contract Verizon phones at the fruit store. They're unlocked GSM global phones, pretty sweet. I got one because they were all my store had and immediately popped in my T-Mo SIM.

> ... Facebook iOS apps make liberal use of web views (and code push)

The Facebook apps absolutely do not use web code anymore. Their native code is conditionally enabled remotely.

As an example (I'm not the guy who you responded to), I've been frustrated in Castro a number of times while looking at an episode in show's feed because the native swipe-back gesture takes you back to the list of shows rather than than that show's feed, and it gets especially annoying considering the lengths of the transitions involved. It's obnoxious, and something one would get used to, but I seem to keep forgetting it. It's one of a few elements of navel-gazing "over"-design… of course the user would follow the steps, they're the steps! They're right there in the design.

The "function trampoline" that's described looks more or less like the Block ABI. Some good learning is available in the source for `libclosure`, [Language Specification for Blocks](http://www.opensource.apple.com/source/libclosure/libclosure...) and [Block Implementation Specification](http://www.opensource.apple.com/source/libclosure/libclosure...).

----

Consistently being able to hook functions in Swift is going to be a pain in release mode optimizations, as the Swift compiler does aggressive inlining.