Category Archives: Swift

How to upload iOS App onto iPhone

XcodeI’ve been working on a hobby project for a while, learning Swift and gaining some experience of iOS App development. I reached the stage where the app was worth testing on my iPhone, but found that my version of Xcode (an early v7 beta) required an Apple Developer Licence!

Fortunately, it turns out that upgrading to Xcode 7.2 meant that I could upload to my own phone simply by providing my Apple ID. The upgrade was much easier than I had expected, compared to the number of bad reports on the internet. I used the App Store to upgrade, maybe it’s harder if you download and install the application directly.

Next, I had to find out how to install an application on my device from Xcode. First, connect the device to the Macbook and it will appear in the device list in Xcode above the simulated devices (i.e. all the iPhone and iPad models). Selecting the device by name and clicking run kicks off a full install and runs the app on the phone.

The final question was how to configure my phone to allow apps written by me to run – this was answered on the Apple Developer Forum, and is simply a matter of becoming familiar with Settings -> General -> Profile / Developer App.

I’m impressed by how well Xcode has automated this process, I’m sure a lot of work has gone into making installation onto a device a positive developer experience.

Leave a comment

Filed under Programming, Swift

How to filter in Swift using where

In F#, it”s common to pipeline a chain of commands together, perhaps filtering an input array before mapping with a function:

let xs = [| 1; 2; 3; 4; 5 |]
xs |> Array.filter (fun x -> x > 2) |> Array.map (fun x -> x*x)

Marcin Krzyzanowski wrote a neat post showing how Swift uses where in a number of cases to achieve similar filtering.

The fact is you can use where keyword in a case label of a switch statement, a catch clause of a do statement, or in the case condition of an if, while, guard, for-in statement, or to define type constraints

Leave a comment

Filed under Programming, Swift

Tutorial: Writing your first iOS App

I’ve finished working through this excellent introduction to writing iOS apps. Having written step-by-step guides for developers learning new software myself, it’s clear just how much work has gone into this guide to make it accurate as well as useful and informative.

  • Having never used Xcode before, the guide did a good job of introducing the development environment and showing the workflow and how to manipulate the various views
  • The FoodTracker application itself covers quite a few techniques – it’s a shame that some of the early lessons are later deleted as the app is built, but it’s a trade-off to get something to run quickly
  • The frameworks clearly do much of the heavy-lifting. This reminds me of writing user interfaces in versions of Visual Basic – you didn’t need to know much of VB as a language, it was more about leveraging the tools to get a result
  • Swift is very concise, parameter syntax takes some getting used to (some parameters have both external and internal names, which is esoteric) but even the passing parameters by name is starting to grow on me.
  • It’s very cool that unit testing is integrated in the dev tools – I’m sure I’ll be writing plenty of tests against my data model when I work on this for real.

I have a couple of ideas for apps that I’d like to write for my new Apple Watch, so next I’m looking to try a tutorial specifically for a Watch app.

Leave a comment

Filed under Programming, Swift

Video: Introducing WatchKit OS2

Catching up with this Intro to WatchKit OS2.  I found the following points interesting:

  • ClockKit has templates for watch kit complications, matching the different shapes and sizes available on the various watch faces
  • Complications should be immediately up to date when viewed, so watch kit allows you to bulk upload e.g. a timeline for a calendar widget that changes during the day.
  • Watch connectivity allows data sharing between phone and watch
  • CoreMotion, CoreLocation, MapKit and HealthKit APIs are available on the Watch

Leave a comment

Filed under Swift, Video

Video: Designing for Apple Watch

I watched this excellent video about Designing for Apple Watch from WWDC.  Some interesting take-aways:

  • Interaction with the watch is expected to be 5 seconds.  Any longer, you should steer the user towards the iPhone (e.g. via hand-off).
  • Notifications on the watch are much more noticeable, so should be kept to a minimum
  • The force-touch provides a context-sensitive menu whichever screen the user is on.  Although it’s less discoverable, it avoids the need for multiple swipes to reach an action screen.
  • The watch has a bezel!  But it’s only visible if your app doesn’t have a black background.  Interestingly, one of their recommend Apps, Toby (a cute dog) has a blue background that breaks Apple’s own guidelines.
  • Their are guidelines for the haptic/auditory feedback for events such as Notification, Up, Down, Success, Failure, Retry, Start, Stop, Click.  For consistency, Apple need *every* developer to use the right effect with the right event – otherwise, users won’t intuitively know the meaning across different App contexts.
  • The click event is interesting – it gives granularity to adjustments, but could easily be over-played – so it’s recommend to exercise restraint.
  • There are templates for glances – and they should “deep link” to the main App for more information.  Again, consistency of layout between the glances for different Apps is important to the continuity of experience for users.
  • Sessions are available for longer interaction with a watch app, intended for fitness apps (e.g. a period in the gym). Yet again, it’s easy to see App developers over-using this feature to avoid the watch returning to the time screen.

Much relies on Apple policing these guidelines, which could be a lot of work.

Leave a comment

Filed under Swift

Swift: Tutorial

swiftHaving recently purchased an Apple Watch, I’ve decided to learn Swift so that I can write a couple of Apps. So far, I’ve been very impressed with the language.

Here’s the link to the tutorial.

However, I’m completely bemused by the rules for named parameters. Unlike in F#, which optionally supports named parameters in calls to function if you want to use them, Swift 2.0 enforces that you must use them (except where you mustn’t, like the first parameter in the call). Seriously? I understand that, for functions with multiple parameters of the same type, it can be helpful to name the parameters – but making that a requirement on every call will seriously reduce productivity.  And what about refactoring – if I change the name of a parameter, will I have to change its name at all call sites as well?

Leave a comment

Filed under Swift