└── README.md /README.md: -------------------------------------------------------------------------------- 1 | # Swift Summit 2 | 3 | 291 days after the launch of the Swift programming language, Swift Summit was held in London, March 21st 22nd. What an amazing 2 days it was. I met some amazing people, learnt some incredibly interesting and thought provoking things, and came away highly inspired and enthusiastic about the future of iOS development. 4 | 5 | Many thanks to Beren Rumble ([@devberen](http://www.twitter.com/devberen)) , Ida Kristiansson ([@NomadicIda](http://www.twitter.com/NomadicIda)) and Morgan Evetts ([@morqon](http://www.twitter.com/morqon)) for organising and hosting such an amazing event. 👏 6 | 7 | Swift Summit [website link](https://www.swiftsummit.com), [twitter link](http://www.twitter.com/swiftsummit). 8 | 9 | --- 10 | 11 | Here are the notes I took. They should not be considered definitive or 100% accurate to the content presented, they are more just a reminder of some cool and interesting things that were said. Where possible I have tried to find links to the slides or presentation material. 12 | 13 | **Pull requests to correct inaccuracies are very welcome.** 14 | 15 | ## Functional View Controllers 16 | 17 | By **Chris Eidhof**, [@ChrisEidhof](http://www.twitter.com/ChrisEidhof) 18 | 19 | * View controllers have a tendency to do a lot of things. 20 | * Setup views. 21 | * Load data. 22 | * Show new view controllers. 23 | * etc... 24 | * Use functional techniques to solve this problem. 25 | * See the "flow" of the application: 26 | 27 | ```swift 28 | let flow = navigationController(loginViewController()) >>> orgsScreen >>> reposScreen >>> issuesScreen 29 | ``` 30 | 31 | * No need to create view controller subclasses. 32 | * Complete decoupling of view controllers from data and other view controllers. 33 | 34 | GitHub repo: [chriseidhof/github-issues](https://github.com/chriseidhof/github-issues) 35 | 36 | Shortly after Swift Summit Chris shipped [Scenery](https://www.getscenery.com/); a Mac app written entirely in Swift. He wrote his thoughts on using Swift in production [here](http://chris.eidhof.nl/posts/scenery-launch.html). 37 | 38 | ## Share Your Code, Swift API Design: Getting Results 39 | 40 | By **Brian Gesiak**, [@modocache](http://www.twitter.com/modocache) 41 | 42 | [Slides](https://github.com/modocache/talks/blob/3a0feaa5db7fc6c8fef8444772b99f7a930f29a4/swiftsummit.key?raw=true) 43 | 44 | * How do you write code other people want to use? 45 | * How do you write *compelling code*? 46 | * Code should be: 47 | 1. Precise 48 | 2. Convenient 49 | * When you have to write documentation to explain code, users will not read it and ultimately it is not precise. 50 | * LLamaKit ([repo](https://github.com/LlamaKit/LlamaKit)) includes `ResultType` which allows for a more precise way for error handling. 51 | * "Railway Oriented Programming" concept facilitates handling errors that can occur at different times. 52 | * Uses `map` and `flatMap` 53 | * `map` when you only have a collection of values. 54 | * `flatMap` when you have a collection of failable results. 55 | 56 | Gift ([repo](https://github.com/modocache/Gift)) for interacting with the GitHub API in Swift, which uses the railway concept 57 | 58 | Brian's [retrospective blog post](http://modocache.io/swift-summit) on Swift Summit. 59 | 60 | ## Closures In API Design 61 | 62 | By **Hermés Piqué**, [@hpique](http://www.twitter.com/hpique) 63 | 64 | [Slides](https://speakerdeck.com/hpique/closures-in-api-design) 65 | 66 | * Closures are self contained blocks of functionality 67 | * UIAlertController is block based. 68 | * Closures encourage code locality, particularly in comparison to the delegate pattern. 69 | * `@autoclosure` is for parameter values we may not use. Looks like it automatically wraps the parameter in a closure for use inside the function. 70 | * `@noescape` is for parameters that will not outlive the function call. 71 | * no-op as default parameter for closures. 72 | 73 | ## Back To The Futures 74 | 75 | By **Javier Soto**, [@Javi](http://www.twitter.com/Javi) 76 | 77 | [Slides](https://speakerdeck.com/javisoto/back-to-the-futures). 78 | 79 | * Do not use NSError. 80 | * Too easy to just pass `nil` - I often do 81 | * Do you check the domain? 82 | * Do you check the error code? 83 | * Probabbly not - I often don't 84 | * Better to create your own `ErrorType` to define the error cases which you care about. 85 | * Introduces Futures, also known as Promises. 86 | * Encapsulate a deferred computation. 87 | * More declarative for failable asynchronous computation. 88 | * Errors are carried though. 89 | * Look really cool and useful having implemented (attempted) asynchronous operations before. Will make things *much* clearer. 90 | * Futures are related to Reactive Cocoa. 91 | * In fact Signals > Futures. 92 | * Futures only work 1 day. 93 | * Signals allow objects to be told about things that happen in the future as well as say what things should happen. 94 | * Reactive Cocoa 3 is in alpha and uses Swift. 95 | 96 | Playground demo [link](https://github.com/JaviSoto/Talks/tree/master/SwiftSummit2015). 97 | 98 | ## The Monad Among Us 99 | 100 | By **Al Skipp**, [@ChromophoreApp](http://www.twitter.com/ChromophoreApp) 101 | 102 | [GitHub repo](https://github.com/alskipp/Swift-Adventures-In-Monad-Land) 103 | 104 | * Code without `nil` is saner code 105 | * Optionals are simple values, but they do add complexity 106 | 107 | ## Static Types and Zero-Cost Abstractions 108 | 109 | By **Airspeed Velocity**, [@AirSpeedSwift](http://www.twitter.com/AirSpeedSwift) 110 | 111 | * Structs pay no runtime penalties like classes do. 112 | * Don't unintentionally rewrite the standard library functions. 113 | * For example, `sort` is very efficient. Use it to sort your own data types rather than writing your own (less efficient) implementation. 114 | 115 | ## How Swift is Swift? 116 | 117 | By **Joseph Lord**, [@jl_hfl](http://www.twitter.com/jl_hfl) 118 | 119 | [Slides](http://blog.human-friendly.com/how-swift-is-swift) 120 | 121 | * Swift is designed for speed. 122 | * Use `final` for classes. 123 | * Use constants with `let` 124 | * `ContiguousArray` is more performant for arrays of `NSObject` 125 | * For performance avoid 126 | * global / class / static vars 127 | * Function calls that cannot be inlined. 128 | * `@objc` objects 129 | 130 | ## What Haskell Taught Me About Writing Swift 131 | 132 | By **Abizer Nasir**, [@abizern](http://www.twitter.com/abizern) 133 | 134 | [Slides](https://speakerdeck.com/abizern/what-haskell-taught-me-about-writing-swift) 135 | 136 | * Favour structs over classes as much as possible. 137 | * Do not mutate structs. 138 | * Use [lensing](http://chris.eidhof.nl/posts/lenses-in-swift.html) approach. 139 | * `typealias` is useful for making code cleaner. 140 | * Higher order functions are easier to read. 141 | 142 | Recommended books: 143 | 144 | * [Learn You A Haskel For Great Good](http://learnyouahaskell.com) Book 145 | * [Real World Haskell](http://book.realworldhaskell.org) Book 146 | * [Functional Programming In Swift](http://www.objc.io/books/) 147 | 148 | ## Swift Scripting 149 | 150 | By **Ayaka Nonaka**, [@ayanonagon](http://www.twitter.com/ayanonagon) 151 | 152 | [Slides](https://speakerdeck.com/ayanonagon/swift-scripting), [Git Repo](https://github.com/ayanonagon/talks/tree/master/swiftsummit) 153 | 154 | * Design assets difficult to keep track of. 155 | * Use a cocoapod for images and other assets designers create that are used in apps. 156 | * Designers make a pull request on the cocoapod repo. 157 | * UIImage category is automatically created to make each asset available in code. 158 | * Not sure how this works when using `.xcassets`? 159 | * [@indragie](https://twitter.com/indragie)’s [swiftsrc](https://github.com/indragiek/swiftrsrc) (also written in Swift!) looks like a great option to achieve the same result if you are using `.xcassets`. 160 | * Category creation is done with a script... in Swift! 161 | * Writing Swift scripts is a good way to learn Swift before writing it for production software. 162 | * Get access to all the frameworks in iOS within your script. 163 | * [Carthage](https://github.com/Carthage/Carthage) is a dependency manager that builds a framework to integrate with your code. Works well with Swift scripts that live outside an Xcode project. 164 | * [cocoapods-rome](https://github.com/neonichu/Rome) works in a similar way by building a framework. 165 | * Carthage vs Rome. Get it? 166 | 167 | ## JSON, Swift and Type Safety: It’s a wrap 168 | 169 | By **Anthony Levings**, [@SketchyTech](http://www.twitter.com/SketchyTech) 170 | 171 | [Slides](http://www.slideshare.net/AnthonyLevings/json-swift-and-type-safety-its-a-wrap) 172 | 173 | * A number of approaches to dealing with JSON parsing in swift. 174 | * Enum type wrapping approach uses associated values. 175 | * Used in. 176 | * [Argo](https://github.com/thoughtbot/Argo). 177 | * [Swiftz](https://github.com/typelift/swiftz) 178 | * [json-swift](https://github.com/owensd/json-swift). 179 | * Also [Iolcos](https://github.com/sketchytech/Iolcos) and [Aldwych ](https://github.com/sketchytech/Aldwych_JSON_Swift), which uses principles outlined in the talk. 180 | 181 | Wonderful use of a drama-school-esque prop. Good work! 182 | 183 | ## Death By Indecision 184 | 185 | By **Alexsander Akers**, [@a2](http://www.twitter.com/a2) 186 | 187 | [Slides](http://www.slideshare.net/pandamonia/death-by-indecision) 188 | 189 | * Emoji-Driven-Presentation 📈😃👍 190 | * Everyone has a side project. 191 | * Weird when you think about it really. 192 | * Consider a farmer: After a hard day of harvesting crops, do they go home and work on their crop harvesting side project? 193 | * Parkinson's law states "work expands so as to fill the time available for its completion". 194 | * Something will take as much time as you set your self, not less. 195 | * Set (stricter) deadlines to stop this. 196 | * Work with other people to ship something. 197 | * Commit to talking. 198 | * Open source while the code is still embarrassing so you *have* to fix it. Keeping it private gets you off the hook. 199 | 200 | If you have a OSS Swift app contact Beren Rumble ([@devberen](http://www.twitter.com/devberen)) and he can help promote and share it. 201 | 202 | ## Extracurricular Swift 203 | 204 | By **Sally Shepard & Mark Martin**, [@mostgood](http://www.twitter.com/mostgood) & [@urban_teacher](http://www.twitter.com/urban_teacher) 205 | 206 | [Slides](http://www.slideshare.net/mostgood/extracurricular-swift) 207 | 208 | * Swift can *totally* be used in education for teaching programming 209 | * The language itself is great, but the tooling is not there yet. 210 | 211 | Links: 212 | 213 | * [http://www.runswiftlang.com](http://www.runswiftlang.com) to run Swift in the browser. 214 | * [https://www.codeclub.org.uk](https://www.codeclub.org.uk) 215 | * [http://www.stemnet.org.uk](http://www.stemnet.org.uk) 216 | 217 | ## (Functional) Programming For Everyone 218 | 219 | By **Daniel Steinberg**, [@dimsumthinking](http://www.twitter.com/dimsumthinking) 220 | 221 | [GitHub repo](https://github.com/dimsumthinking/TurtlePlayground): Swift playground using Logo-like commands to teach kids programming. 222 | 223 | * Playgrounds with swift can be used for teaching children to code. 224 | * Realtime inline feedback! 225 | * Playgrounds now get their own directory structure much like an Xcode project. 226 | * Allows you to provide helper code. 227 | * And a place where children can put their own implementations. 228 | 229 | * Interesting question: **Should we teach kids functional programming from the start rather than procedural programming?** 230 | * Interesting answer from Daniel: (paraphrasing)**In the same way I don't want kids to be drinking alcohol, I'm not sure how much functional programming they should be doing either!** 231 | 232 | ## Day 1 Panel Discussion 233 | 234 | Panel: [Brian Gesiak](http://www.twitter.com/modocache), [Ayaka Nonaka](http://www.twitter.com/ayanonagon), [Chirs Eidhof](http://www.twitter.com/ChrisEidhof) & [Airspeed Velocity](http://www.twitter.com/AirSpeedSwift) 235 | 236 | * Swift can be a backend language, but it is the infrastructure that is missing, like Heroku and AWS. 237 | * Exciting to see the development of a new language that is less than a year old! 238 | * Apple changing the language based on our feedback. 239 | * We can decide it's destiny. 240 | * We can decide the best practises. 241 | * An amazing opportunity. 242 | 243 | The big question: **Is Swift ready for production?** 244 | 245 | Fantastic answer from Ayaka: **Do you think Objective-C is ready for production?** 246 | 247 | ## let swift: Race? 248 | 249 | By **Jack Nutting**, [@jacknutting](http://www.twitter.com/jacknutting) 250 | 251 | [Slides](http://assets.nuthole.com/swiftsummit2015_jacknutting.pdf) 252 | 253 | * Starts off with a [translation of a Bible quote into Swift](https://twitter.com/jacknutting/status/580284786339647488/photo/1). 254 | * He has not written any Objective-C since November. 255 | * Advice is not not just use Swift for the sake of it - be pragmatic. 256 | * After all Objective-C is not a bad thing. 257 | * Nested method calls like `[[[object foo] bar] baz]` isn't just bad syntax, it is bad form. 258 | * When using Swift, don't just use enums where subclassing would be better for customisability. 259 | * Inheritance and polymorphism are good things, use them! 260 | * Subclassing and comparability are sometimes better than using enums. 261 | * If a huge chunk of code revolves around switching on an enum, maybe using classes would be better. 262 | * Using `final` limits customisation through subclassing. 263 | * However, future developers will want the flexibility to extend your system in ways you cannot foresee. A compromise is therefore necessary, 264 | * "Premature optimisation is the root of all evil". 265 | * Remember functional programming is not a silver bullet. 266 | * Use the [lensing](http://chris.eidhof.nl/posts/lenses-in-swift.html) approach to avoid mutability. 267 | 268 | 269 | ## Swift, Meet Objective-C 270 | 271 | By **Daniel Tomlinson**, [@dantoml](http://www.twitter.com/dantoml) 272 | 273 | [Slides](https://speakerdeck.com/danieltomlinson/swift-meet-objective-c) 274 | 275 | * "All Objective-C you write now is technical debt". *Controversial* 😮 276 | * Swift is the future, we need to look to it. 277 | * Try building new APIs in Swift. 278 | * Experiment when building new features. 279 | * Remember, you can use Objective-C and Swift together. 👫 280 | * Bridging exposes Objective-C headers to Swift. 281 | * Previously when using Objective-C APIs in Swift there was a mess of implicitly unwrapped values. Additions in Obj-C to help this: 282 | * `__nullable` 283 | * `__nonull` 284 | * `__null_resetable` for properties 285 | * `__null_unspecified` is the default 286 | * What you **do** get when using Swift code in Objective-C (limited to the runtime): 287 | * Classes, but not generics or subclassing. 288 | * Protocols 289 | * Methods 290 | * No generic methods 291 | * No default methods 292 | * Properties 293 | * No KVO 294 | * Cannot be swizzled, except when using the `dynamic` keyword 295 | * Enum, which is converted to NSEnum 296 | * No associated values 297 | * What you **don't** get: 298 | * Structs 299 | * Functions 300 | * Operators 301 | * Generics 302 | * WWDC 2014 videos 406 & 407 go through a lot. 303 | * Advice: create your API in Objective-C and then bridge to Swift. Pick which one you want. 304 | * Remember to include what namespace you want when using `@Objc`, other wise you will lose it. 305 | 306 | ## Swift Funtime 307 | 308 | By **Boris Bügling**, [@NeoNacho](http://www.twitter.com/NeoNacho) 309 | 310 | [Slides](https://speakerdeck.com/neonichu/swift-funtime-2) & [Github Repo](https://github.com/neonichu/swift-funtime) 311 | 312 | * Boris is on the core team at cocoapods. 313 | * In Swift import `ObjectiveC.runtime` 314 | * You can use dynamic introspection for Swift objects. 315 | * The `reflect` method is in the standard library, but it is private so be careful. 316 | * `NSInvocation` does not exist in Swift. 317 | 318 | ## Testing In Swift 319 | 320 | By **Jan Riehn**, [@jriehn](http://www.twitter.com/jriehn) 321 | 322 | [Slides](https://speakerdeck.com/jriehn/testing-in-swift-swiftsummit-2015) & [GitHub Repo](https://github.com/jriehn/testing-in-swift) 323 | 324 | * Testing is an art. 325 | * Creative. 326 | * Challenging. 327 | * Swift offers some reflection, but it is private, so don't use it. 328 | * Cannot set variables through reflection so don't use it. 329 | * Learn to create your own test doubles rather than relying on mocking. 330 | * This is easier and nicer in Swift as you can do it inline. 331 | * You can use OCMock in Swift with some setup. 332 | * But restricts you writing your tests in Objective-C 😞 333 | * Create different test classes. 334 | * One for the success cases. 335 | * One for the failure cases. 336 | * Separate your UI from the business logic. 337 | * Create thin view controllers. 338 | * From Swift 1.2 onwards no need to add your production test code to the test target. 339 | * OCHamcrest has nice syntax for optionals. 340 | 341 | ## Debugging In Swift 342 | 343 | By **Carola Nitz**, [@_Caro_N](http://www.twitter.com/_Caro_N) 344 | 345 | [Slides](https://speakerdeck.com/carola/debugging-in-swift) 346 | 347 | * Swift can be hard to debug. 348 | * Output from lldb it not helpful. 349 | * Error messages make no sense. 350 | * In lldb, `po` is just an alias for `expression -O -- myObject` 351 | * For nicer output use `expression -l objc -O -- (id) ` 352 | * Utilise conditional breakpoints. e.g. play a sound for feedback. 353 | * Use exception breakpoint. 354 | * Use symbolic breakpoints. 355 | * Stop when a method is called. 356 | * Can also stop on private methods. 357 | * Tips for dealing with compilation errors: 358 | * Remove variables. 359 | * Split up instructions. 360 | * You can use launch arguments passed at the start to override defaults. 361 | * In the scheme editor: 362 | * Add concurrency arguments for Core Data to check for thread safety. 363 | * `SQLDebug` 364 | * `NSDoubleLocalizedStrings 1` 365 | * `NSShowNonLocalisedStrings 1` 366 | * `AppleLanguages (es de)` 367 | * Use can use the Swift repl from inside lldb. 368 | * run `xcrun swift` to clean the repl session. 369 | * You can use activity tracing with breadcrumbs. 370 | * Included in the crash report, 371 | * However cannot log strings for user privacy. 372 | * More info in objc.io 373 | 374 | ## Swifty Methods 375 | 376 | By **Radek Pietruszewski**, [@radexp](http://www.twitter.com/radexp) 377 | 378 | [Slides](http://www.slideshare.net/radexp/swifty-methods-swifty-apis) & [related blogpost](http://radex.io/swift/methods) 379 | 380 | * Focus on clarity 381 | * Don't write clever code. "Keep it simple, stupid". 382 | * Clarity ≠ Verbosity. 383 | * Find the sweetspot between brevity and verbosity. 384 | * This is where clarity lies. 385 | * Remove the noise. 386 | * Good example of this is the `replace` string method, and a rewrite of [NSTimer](www.radex.io/swift/nstimer). 387 | * Have an open mind when writing Swift. 388 | * Programs must be read as well as executed. 389 | * Use default arguments for methods that usually take arguments. 390 | 391 | ## Crypto Swift 392 | 393 | By **Marcin Krzyżanowski**, [@krzyzanowskim](http://www.twitter.com/krzyzanowskim) 394 | 395 | [GitHub Repo](https://github.com/krzyzanowskim/CryptoSwift) 396 | 397 | * Common Crypto framework available in Swift. 398 | * SwiftSSL is a Swift wrapper around CommonCrypto. 399 | * NaCL (Salt). 400 | * Crypto Swift is pure Swift framework, but is slower. Supports: 401 | * Hashing 402 | * Symmetric Ciphers 403 | * Block Cipher 404 | * AES 405 | * ChaCha20 406 | * Authenticators 407 | 408 | ## Swift & Metal 409 | 410 | By **Simon Gladman**, [@FlexMonkey](http://www.twitter.com/FlexMonkey) 411 | 412 | [Slides](https://speakerdeck.com/flexmonkey/ios-gpu-programming-with-swift-and-metal) & [related blogpost](http://flexmonkey.blogspot.co.uk/2015/03/swift-metal-four-million-particles-on.html) 413 | 414 | * Metal is faster then SceneKit as it is lower level. 415 | * But there is more of a development overhead. 416 | * Has C++ style syntax. 417 | 418 | ## Taylor Swift HTTP Framework 419 | 420 | By **Jorge Izquierdo**, [@izqui9](http://www.twitter.com/izqui9) 421 | 422 | [GitHub repo](https://github.com/izqui/taylor) 423 | 424 | * Taylor is an HTTP server written in Swift. 425 | * Can use Taylor in Playgrounds. 426 | * Can embed it in your app for workarounds with WKWebView. 427 | 428 | ## View From The Otherside 429 | 430 | By **Gem Barrett**, [@gembarrett](http://www.twitter.com/gembarrett) 431 | 432 | * Stereotype of Apple developers from web developers: 433 | * Don't touch this. 434 | * Unstable. 435 | * Secrecy, lack of open source. 436 | * Web / Native / Hybrid argument 437 | 438 | ## RESTful 439 | 440 | By **Kyle Fuller**, [@kylefuller](http://www.twitter.com/kylefuller) 441 | 442 | [Slides](https://speakerdeck.com/kylef/embracing-change-with-rest) 443 | [Representor](https://github.com/the-hypermedia-project/representor-swift) - Hypermedia resource framework in Swift 444 | 445 | * Kyle is the tech lead at CocoaPods 446 | * REST is for good API design 447 | * Lets us embrace change 448 | * You should anticipate change. 449 | * Facebook freeze their API for 2 years to ensure compatibility. 450 | * REST promotes change. 451 | * Take on Mark Zuckerberg quote: "Move fast and *dont* break things." 452 | * REST let's us embrace change, so we can move fast and break nothing. 453 | * REST is not about exposing a database. 454 | * Design your API around representations, i.e. states. 455 | * This avoids coupling implementation details, which can change. 456 | * HATEOAS is a REST constraint. If you are not using HATEOAS you are not doing REST. 457 | * API can be dynamic in what things it can do. 458 | * Client is taught about the semantics so it can discover things for itself. 459 | * Gracefully handle features that the API lacks / turns off. 460 | * Use the SIREN JSON format for hypermedia. 461 | 462 | [Representor](https://github.com/the-hypermedia-project/representor-swift): Swift library for building and consuming Hypermedia messages 463 | 464 | A collection of REST (HATEOAS) APIs: 465 | 466 | - [Polls API](https://github.com/apiaryio/polls-api) - Siren and HAL, completely OSS and configurable. 467 | - [PayPal API](https://developer.paypal.com/docs/api/#hateoas-links) - HAL 468 | - [Heroku](https://blog.heroku.com/archives/2014/1/8/json_schema_for_heroku_platform_api) - JSON Schema 469 | - [GitHub](https://api.github.com) - Custom (url in responses) 470 | - [Artsy](http://artsy.github.io/blog/2014/09/12/designing-the-public-artsy-api/) - HAL 471 | - [FizzBuzz as a Service](http://smizell.com/weblog/2014/solving-fizzbuzz-with-hypermedia) - Siren 472 | 473 | ## Day 2 Panel Discussion & Closing Remarks 474 | 475 | * Exploring new concepts in Swift we didn't have in Objective-C. 476 | * You could use 👍 and 👎 emoji to indicate success and failure. 477 | * We still need dynamic features in Swift as we have to use Objective-C for them still. 478 | * Swift tooling needs improving. 479 | * We can decide and make the best practises ourselves - golden opportunity. 480 | * Be pragmatic about using Swift and Objective-C. 481 | * Core Data is ripe for Swift rework. *Hell Yes* 482 | * Maybe Apple would open source Swift? Only a question of when? 483 | * Open sourcing would lead to Swift web frameworks as it would be available on every platform. 484 | --------------------------------------------------------------------------------