
WWDC 2017 and What It Means for Developers - gk1
https://blog.clubhouse.io/wwdc-2017-and-what-it-means-for-developers-76c5e5736fb8
======
aparadja
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.

~~~
microcolonel
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.

~~~
skybrian
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.

------
shanev
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](https://twitter.com/shanev/status/873225569164546048).

------
pjmlp
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.

~~~
charlesdm
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.

~~~
dep_b
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.

~~~
pjmlp
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.

~~~
dep_b
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.

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

~~~
0x0
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.

------
stiGGG
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?

~~~
rimliu
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.

------
singularity2001
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.

~~~
aparadja
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.

~~~
pjmlp
> 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.

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

