4 ms·

WWDC 2017 and What It Means for Developers

45 points by gk1 9y ago

pjmlp 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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 9y ago
        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.
  - gurkendoktor 9y ago
    > 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.
    - valuearb 9y ago
      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.
  - pjmlp 9y ago
    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.
  - giobox 9y ago
    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.
topochico 9y ago
Swift is actually very performant, and I think the XCode updates are particularly exciting
stiGGG 9y ago
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 9y ago
  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.
- kalleboo 9y ago
  Another hint is they made the reception indicator less wide (went back to bars from dots)
singularity2001 9y ago
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.
- shanev 9y ago
  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.
- aparadja 9y ago
  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 9y ago
    > 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.
- valuearb 9y ago
  I love the higher level APIs
aparadja 9y ago
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 9y ago
  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 9y ago
    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.
  - pjmlp 9y ago
    For the developers at WWDC 2017 none of those items are relevant.
- orf 9y ago
  Does this mean little snitch may stop working?
shanev 9y ago
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.
ponytech 9y ago
Biggest annoucement to me : drop of 32 bits support. Thousands of apps will just stop working.
- 0x0 9y ago
  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.

45 points by gk1 9y ago

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 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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.
- gurkendoktor 9y ago
  > 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.
  - valuearb 9y ago
    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.
- pjmlp 9y ago
  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.
- giobox 9y ago
  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.

topochico 9y ago

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

stiGGG 9y ago

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 9y ago
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.
kalleboo 9y ago
Another hint is they made the reception indicator less wide (went back to bars from dots)

singularity2001 9y ago

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.

shanev 9y ago
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.
aparadja 9y ago
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 9y ago
  > 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.
valuearb 9y ago
I love the higher level APIs

aparadja 9y ago

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 9y ago
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 9y ago
  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.
- pjmlp 9y ago
  For the developers at WWDC 2017 none of those items are relevant.
orf 9y ago
Does this mean little snitch may stop working?

shanev 9y ago

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.

ponytech 9y ago

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

0x0 9y ago
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.