WWDC 2017 and What It Means for Developers | Hacker News Reader

WWDC 2017 and What It Means for Developers

blog.clubhouse.io

45 pointsgk128 comments

It was also almost offhandedly announced (in session 707) that they are deprecating network kernel extensions, with no real replacement API in sight.

That's an existential crisis for 3rd party firewalls.

macOS is a wasteland, if anyone is investing in it today then they are a fool or have been fooled.

The IPC performance is still abysmal (noticeable latency in several applications) after 16 years of kernel development. The scheduler is meh, the features offered by the kernel are generally meh. The UI and multimedia libraries were quite good, but they neutered them by incrementally removing customization opportunities, and now there's little left. No way to install a codec or container in Core Audio or Core Video, so you can't play or Quick Look Opus or VP9 or a Matroška file in standard applications. Their OpenGL drivers are garbage, absolute putrid garbage, especially on the integrated graphics; they still only support OpenGL 4.2 (read: the year 2011) on any GPU, and on Intel's GPUs performance is often 60% worse than performance on Linux and Windows (which are generally on par). If their Metal implementation shares its shader compiler with their Intel OpenGL implementation, then it's likely that you will never see any performance benefit from Metal on Intel graphics because your application is probably shader bound due to their drivers. And if we're being fully honest, if they were trying to make developer lives easier, they would add Vulkan support, but they refuse.

Wow, as a user I don't care all that much about any of that.

I expect many users will feel the same, so developers will keep making apps for them.

For the developers at WWDC 2017 none of those items are relevant.

Does this mean little snitch may stop working?

That's certainly what it looks like. They told developers to "talk to us" if the change is a problem. I opened a support ticket immediately, but haven't yet heard back. I'm sure the people at ObDev have done the same.

Things like murus[1] will still work although it leverages the first party firewall (pf)

[1] http://www.murusfirewall.com

ARKit is fun and easy to get started with. Plane detection works even on a clear glass surface. Here's a demo of a fidget spinner I made: https://twitter.com/shanev/status/873225569164546048.

After going through all the sessions, I think the message is that Apple is going full speed on Swift, regardless how devs might feel like, similarly to Google with Java/Kotlin[1] and Microsoft with .NET/C++.

Besides the LLVM related talks, Metal shaders and real time audio callbacks, there is hardly any C like code to be seen across all sessions.

[1] On Android, NDK is seen as only to bring in code or implement native methods.

I wonder how likely it'll be they keep Objective-C support. Ultimately, there's a huge amount of useful legacy code available they would be throwing away.

I think the way it's set up right now with interoperability works pretty well, and using it for new apps is a great idea, but forcing people to throw away existing apps that have been around for years.

Forever. It's much easier when you deal with low level code from Objective-C(++) and Apple has tons of that written with no obvious benefit when it's rewritten in Swift.

They might introduce modules that are incompatible or awkward to use with Objective-C in the future though.

The benefit are dogfooding and public image.

Microsoft already did it multiple times when VS team had to adopt WPF, the new APIs that are COM only or latest example having the Office team adopt the desktop bridge and make it a UWP only application on Windows 10.

If anything, to give the message to the world that the internal teams also use the technology they are trying to sell.

And they are slowly doing it, given that launchd and the Dock were rewriten in Swift for Sierra and the new XCode 9 build system is now in Swift, as well as some parts of the Store app.

Yeah I remember people being really sceptic in the beginning that Apple wouldn't even use Swift for it's own projects. People pretending to have "inside knowledge" nobody uses Swift at Apple internally, claims like that.

You have to silence those critics.

> using it for new apps is a great idea

The Swift 2->3 migration was a huge time sink and is still on people's minds. Xcode 9 is also still slow and crashy when working with Swift. For small apps with a tiny maintenance budget, ObjC makes a lot of sense even now. I expect it'll die even more slowly than Carbon did.

Note that the Swift 4 migration is intentionally easy and backwards compatible with 3.2. I think they learned a good lesson from the ->3 migration.

Which is why all Objective-C language features introduced since Swift were to make interop between the languages easier, and also why some Swift design decisions were to make it easier to seamlessly use the Objective-C's runtime.

My general feeling is the consensus is that dropping objective-c support is a decade or more away at the earliest. IIRC Latner has said in the past deprecating objective-c was never really a primary goal, one of the reasons for the effort in adding new features to objective-c in recent years to fully support Swift/Objective-c interop.

Apple have so much objective-c code in production, probably more than other firm. Their engineers are still going to need IDE and tooling support for their giant objective-c code bases for many years to come.

As with previous transitions in Apple's software ecosystem, it will also probably depend on what the big bears in the third party software market tell Apple they need - as big as Apple now are, third party applications like photoshop, office etc are still arguably hugely important to the overall health of MacOS especially as a platform.

Biggest annoucement to me : drop of 32 bits support. Thousands of apps will just stop working.

I agree, this is painful. I understand they might not want to maintain 32bit versions of all their libraries (uikit etc), but there are many many useful apps (for example, hardware specific configuration utilities) that aren't being updated. It would be wonderful if 32bit support was available, perhaps as an optional download. Even hiding 32bit apps in the appstore for users who haven't already "purchased" these apps is OK, but it wouldn't hurt non-32bit-users if 32bit support for existing purchases was still available. But for users with important 32bit legacy applications, having the apps run at all is more important than any type of performance and disk space loss caused by having duplicate 32bit and 64bit sets of libraries. Even if 32bit UIKit doesn't get updated with new iOS11 features like drag&drop.

Apparently, macOS 10.13 will also be the last macOS to run 32bit x86 mac apps "without compromise". While unfortunate, that's not too bad since you can always run a VM with an older version of macOS for those kinds of apps, something that is impossible on iOS.

Are the new UIView.safeAreaLayoutGuide and UIView.safeAreaInsets APIs a hint for an iPhone 8 with an screen covering the complete frontside and a home button built into the screen? What do you think?

Probably reading too much into it. The things you mention should be taken care by OS, app should not even be aware they are available. New guides and insets help if you use new header styles, which cant take a lot of space.

Another hint is they made the reception indicator less wide (went back to bars from dots)

Anyone else disgusted by Apples APIs?

func BNNSFilterCreateConvolutionLayer(UnsafePointer<BNNSImageStackDescriptor>, UnsafePointer<BNNSImageStackDescriptor>, UnsafePointer<BNNSConvolutionLayerParameters>, UnsafePointer<BNNSFilterParameters>?) Returns a convolution filter, initialized with input, output, layer, and filter parameters.

Accelerate is a low level C framework that is not representative of all Apple APIs. It's only used directly for very specific use cases. Most of the time you'll be creating neural nets with CoreML which is built on Accelerate and has a much friendlier and higher level API.

That function sure is ugly, but in general they have done a great job in making their own APIs more easy on the eyes.

And even that monstrosity doesn't look that bad in actual use:

  let filter = BNNSFilterCreateConvolutionLayer(&inDesc, &outDesc, &layerParams, &filterParams)

The worst offenders for readability are these C-ish functions that deal with unsafe pointers. But at least in Swift, I appreciate the safety brought by the type checking. It's quite nice that unsafe code is clearly marked.

> The worst offenders for readability are these C-ish functions that deal with unsafe pointers.

That is exactly the point, to make it pretty clear that the code needs to be scrutinized very carefully for its safety.

I love the higher level APIs

Swift is actually very performant, and I think the XCode updates are particularly exciting

Reply on news.ycombinator.com