Those who know what the future brings we call futurists. Those who know when one thing will happen we call billionaires. Entrepreneurs know this and cite timing issues are the primary causes for their success and failure. How do you calibrate your temporal senses? How can you know when to hold them and when to fold them? It turns out that we can learn from history if we know of a theory of industry development. This is a presentation of data and the patterns that support this theory.

This talk covers the use of physics and similar real world effects in your applications to make them, well more physical. Despite Apple’s push towards ugly design (and now slow move back towards something useful) your users still like their apps to work the way the real world works and I think deep down inside Apple knows this. There is a slew of great APIs which are rarely used to make your app a lot more real feeling.

In this session we will take a look at:

• skeuomorphic and playful interactions from both a designer and developer perspective
• some good examples of apps using skeuomorphic design even in the current iOS landscape
• some good examples of apps using playful interactions
• cover the techniques and APIs Apple has provided to use these design elements in your apps
• Live code demo (because they always work) of some of these techniques to show how easy they are to implement

*** User love is not guaranteed.

There’s nothing better than containerizing things. Everybody loves microservices. Brand new programming languages are the new hotness.

In this session, we’ll combine all three: we’ll explore the use of Swift for the construction of microservices, which we’ll containerize using Docker. Learn how to use your mobile development skills for non-mobile Swift development.

Focusing on the Swift open source project’s releases, we’ll walk through Swift setup, installation, community, and tools, and then teach the basics of Swift programming as we create and containerize a simple micro service. We’ll be using Docker for Mac.

By the end of this session, attendees will:

• understand the basics of Swift
• know how to install, and work with Swift on Linux
• know how to build a simple microservice with Swift
• be aware of the possibilities of combining Swift with Docker

We promise, despite the buzzwords, this is actually useful! Inch ever closer to being a full-stack developer using only Swift.

Can a programming language describe art? Is knitting Turing complete? And just how many bytes of data does the average knitted scarf hold, anyway?

These are the questions that motivate Kris as both a knitter and a technologist. As an art form, knitting is inherently binary – just knit and purl. That means you can use sticks and string to encode data in a lot of different ways – like recording the day’s weather, noting enemy troop movements, or even knitting a computer virus. But that’s just the start! Through the act of knitting, the crafter becomes a kind of human CPU, utilising objects and data structures (needles) and free memory (ball of wool) to implement instructions (the pattern). Knitting patterns themselves are very similar to computer languages, with new syntax proposals emerging with innovative constructs and even compilers.

If you thought knitting was just an old-fashioned hobby for grandmas, this talk will open your eyes to the many ways this traditional craft is still relevant in the digital age. (And no, you don’t need to know how to knit!)

Android Studio has a ton of options that can help developers when debugging their applications. This talk aims to demonstrate how to make the most of these features to maximize developers’ debugging efficiency.

This talk will go through the options available for debugging applications on the IntelliJ platform in general, and the Android Studio IDE in particular. Code samples, shortcut keys, and various options and set ups will be shown throughout.

Writing libraries and toolchains for your developer peers can be a challenge. Easy to use, flexible, testable, and extensible are all qualities we strive for when writing software that others will use. Hardware related tools specifically can be especially complex, where extra empathy and thoughtful process is often needed.

This session will be a walk-through of several case studies sourced from personal open source work, written for both the NodeJS Hardware Working Group and the vibrant worldwide Nodebots community at large. Lessons learned will be aplenty, providing some fresh perspectives on how deeply your code can improve the first impressions of those in the communities you wish to cultivate.

How do you create compelling tests? In this talk, Sam Connelly will go through her risk based framework that she developed to help her team create UI automation tests that matter. This approach can also be used for manual testing, generating explorative testing ideas and communicating flows & risks to people outside of your team. We will cover:

• break an app into flows
• map flows to risk board
• break a flow into a test
• create quick and dirty automation testing

You will learn how to have a risk based approach towards your test coverage and learn how to use a whiteboard and sticky notes to communicate testing ideas.

Medical Researchers have made measurements suggesting that application of a Direct Current (DC) voltage prior to and/or during the Radio Frequency Ablation of cancerous tissue can improve the efficiency of the ablation process, resulting in larger areas of ablation than can otherwise be achieved.

A prototype system, consisting of a software-programmable DC power supply incorporating sensors for measurement of Voltage, Current, Power, Impedance and Temperature as well as a control port for controlling a commercial Radio Frequency Ablation System (in this case, a Boston Scientific RF3000) has been built and demonstrated to provide a tool for further research and hopefully in the longer term, equipment useful in clinical situations.

The system is interfaced via a Bluetooth link to an Android or IOS mobile phone or tablet which runs an App that controls and monitors the ablation process. The App can program ablation sequences as a series of steps that define a ””cooking profile”” and continuously monitor and record the measurement parameters. Sequence commands take the form of: ””Apply ramped DC power from 50mW to 100mW over the first 5 minutes, then continue this while further applying an RF Power of 40W for another 5 minutes”“. If measured parameters extend past pre-defined limits, the ablation is cancelled for safety concerns.Data logs (and corresponding ablation sequences) can be saved directly from the phone/tablet to cloud-based storage for further analysis. The system is capable of recording in a matter of minutes what researchers have previously spent years investigating.

This development shows the potential of IoT connectivity and how taking advantage of existing infrastructure such as phones, tablets and the internet can drastically reduce the cost of development of sophisticated systems, because the display, user interface, communications infrastructure and computing platform are already. A relatively small investment in hardware and software can result in powerful connected equipment at a low cost.

As one of the founders of AltConf, I’ve had a unique view on the biggest week of the year for iOS and macOS developers, WWDC. AltConf has grown from a small seed to one of the biggest Apple developer conferences in the world, and a focal point for developers, designers and everyone in the community. We’ve changed over time, but always put the community at the heart of what we do and why we do it.

Join me to hear the origin story of AltConf, how we’ve evolved over the years, as well as the inside stories of our journey, and how we deal with the public pressure and high expectations.

How do you change the fundamental technology your app is built in? How do you rebuild your app gradually, while still shipping regular updates? Those are the questions we faced as Seek, when we concluded PhoneGap, the quick-fix solution we had used to originally create our Android app, wouldn’t allow us to deliver the experiences and features we wanted.

A common approach is to start with a clean slate – do a rewrite. It is a risky and costly approach and we opted for a different solution. Split the problem into smaller, distinct pieces and deal with them one by one. In four stages we went from fully web-based with almost no native capability, to having all the native flexibility we would have if we had started with a clean slate. In this talk, I’ll share the details of how we did it and what we learned in the process.

RxJava has been taking the Android world by storm. There is not a single API in Android that doesn’t have a RxJava wrapper available. Yet the steep learning curve and the overly simplistic examples available can make it hard to grasp the real benefit of RxJava. Many developers are left with questions like:

• Do I really need RxJava if my API responses don’t require mapping and filtering operations?
• Most of my features are simple, is it worth it to implement an RxJava based architecture for simple features?

In this talk we will briefly introduce RxJava and the most important concepts. Next we will look at how you would implement a basic feature in an Android app and we will closely look at the additional benefits that RxJava will provide other than just basic mapping and filtering of data. You will see how threading turns into an afterthought instead of an upfront design decision and the impact this will have on the overall architecture of your app.

Designers will learn how to prototype and design App Store ready app in Interface Builder and Developers will learn how to use @IBDesignable, @IBInspectable and Swift protocol extensions to implement an extendable UI library.

Firstly, we will open Xcode and start with a new iOS app project to demonstrate how to use @IBDesignable and @IBInspectable to implement customised UI elements in Xcode and use them in Interface Builder. After that, we will introduce an open source project IBAnimatable. We will install IBAnimatable using CocoaPods in the project above. Then we will live design customised UI, animations, and transitions in Interface Builder.

In the second part, we will take a further look at how to implement a flexible and extendable UI library using Swift protocol extensions. To demonstrate the power of Swift protocol extensions, we will integrate an existing UI library with IBAnimatable to add animation features. In our case, we use a big enough UI library called Material as an example. Then add animation capability for Material UI elements using Animatable protocol within IBAnimatable. We can use Swift protocol extensions to develop and extend any UI elements.

We will live code in Xcode and live design in Interface Builder during the entire talk. We will also use interactive slides made in Interface Builder. And display them within an iOS app on an iPad Pro.

IOTA (a subsidiary of South East Water) and Hydrix (an engineering consultancy) have developed the OneBox, a device that provides water authorities the ability to control and monitor pumps, pressure sewer units and other remote assets from the office or smartphones. Thousands of these devices have now been deployed in Australia and overseas, without any reported software issues.

This talk will present some of the architectural patterns that were used to maximize reliability of the embedded firmware that resides in OneBox.

The iOS team at REA Group is expanding. This necessitates a better tooling and continuous integration (CI) infrastructure to maintain our agility and speed in delivering app releases. Recognising this, we have improved our process and CI infrastructure by utilising Buildkite and automation tools.

In this talk, we’ll start by discussing our motivation, the previous CI infrastructure, and team requirements. Then, we will talk about the new infrastructure. Specifically:

• Overview of Buildkite and how it meets our requirements
• The overall CI architecture and build machines
• Automating the creation of build machines
• How the new CI integrates with our development process

This talk will be a great opportunity to learn about the challenges we faced and lessons we’ve learnt around automating iOS CI infrastructure at REA Group.

Ephox’s rich text editors, TinyMCE and Textbox.io are two of the most complex and widely used JavaScript applications in the world: around 10 million people use these full-featured textediors every day. Last year, the team at Ephox took on the huge task of porting the 1500 module, shortcut-key driven, keyboard and mouse intensive application from desktop to mobile.

In this example-packed presentation, we share the experiences of our epic journey, the challenges faced, and the surprises that blindsided us. If you are planning to transition your own application from desktop to mobile, or create a new responsive web app, our 7 UX Secrets may just save you months of effort (and preserve your sanity!).

Everybody loves building and shipping apps! It is exciting. However, once the thrill of releasing has died down, the cold hard reality of providing ongoing support for these apps kicks in.

Aimed squarely at developers, tech leads and operations teams, you’ll be presented with some of the common pitfalls that are encountered post go-live, and explore some techniques (both technical and operational) that can be used pre-emptively to make your developers’ and support teams’ lives easier.

Broadly speaking, the presentation will be broken into 5 sections:

• Architecture/Design – A number of architectural and design patterns that can be used to set your project up for success in the long term.
• Development Practices – You’ll learn about some development practices that will assist developers and QA testers to have a predictable and reproducible process.
• Production Support – What information do 1st/2nd/3rd level support teams need to do their job properly? Some common challenges will be presented alongside some battle-tested solutions.
• Changing App Behaviour – Updating apps’ behaviour remotely is de rigueur in today’s mobile world. A number of techniques will be described that can be used to change the behaviour of apps once they have been released into the wild.
• Discovering Problems Before Your Users – Sounds like nirvana, doesn’t it? There are a number of tools at your disposal and some elemental use cases will be outlined.

Testing mobile apps has always been difficult, especially across integration points. When a service has multiple clients, at multiple versions, it makes modifications incredibly difficult. Breakages between an app and service are often discovered late in the development cycle (or after it has been released!) and the causes are difficult to diagnose. Contract testing is an idea that has become very popular in the micro services area, but I believe is equally applicable to mobile applications.

Pact is a tool that was built to test the contracts between micro services. I built a Swift library that conforms to the same specification to allow the same testing methods to be used between an iOS mobile app and a service. With this talk I will show how you can use Pact to test the boundaries between your mobile app and services.

Although the examples in this talk are Swift / iOS specific, the principles around contract testing and the use of Pact are applicable across client / server systems.

Unidirectional Data Flow is the new hotness in UI architecture, but how do we apply this to mobile apps? The easy answer is “Use React Native”, but who would want to take the easy road? Instead, in this talk we’ll go through the key elements of the unidirectional data flow style and look at how to architect this for mobile using an example Swift iOS app.

This will include:

• Defining core application state and leveraging change events to update the view layer
• Wiring up an Action dispatcher to manage state change, including background event
• Approaches to implement navigation flow on top of the UIKit framework

Attendees will gain a clear conceptual understanding of the Unidirectional style, and the practical benefits & drawbacks they’re likely to encounter using it in a mobile app.

Laziness is one of Larry Wall’s “three great virtues of a programmer”, but most people probably don’t consider it a virtue when writing tests! Wouldn’t it be great though, if we could write a program that generates our tests for us? As it turns out, we can and should do this using property-based testing. I’ll go through some example testing scenarios in a few popular mobile programming languages, aiming to demonstrate:

• What property-based testing is and why EVERYONE should be using it (not just people coding in functional languages!)
• How generators can quickly & easily come up with more thorough test inputs than a programmer typing in magic numbers
• How to (and how not to) define properties to specify program behaviour
• The genius of shrinkers and why they can save you hours of tedious debugging and questioning your life choices

Attendees will gain a solid & practical understanding of how they can apply property-based testing to their own code, in fashion that is both enjoyable and lucrative.

Making large big bang releases on the AppStore is an inherently risky and hard problem. From our experience of releasing the largest update to our app a few weeks back, I would like to share some of the strategies and processes we put in place, to reduce the risk of such a release.

I qill also share our experience of creating a new approach to change aversion management. At realestate.com.au, we shipped a few weeks back, the largest update we have made in over 3 years. We did this release while

• running no long running branches. All code in master – behind feature toggles
• Releasing every 4 weeks for the previous 7 months, which are considerably large releases themselves
• Transitioning the whole team to use Swift for nearly 100% of new code
• Changing our underlying persistence layer from Core Data to Realm
• Going from 3 to 10 people in the team
• Distributed team
• On a 6 year old codebase

In this talk, I will provide a blueprint of some of the strategies and processes we put in place to make sure we can make such a release possible.

Some of the strategies I will talk about include Release trains, Engineering docs, Small releases and our approach to tech debts. I will also talk about our approach to minimizing change aversion. We released the new navigation structure behind toggle, which the user can opt into.