Good technology and great products lead to more enriched, enjoyable, and empowered experiences for end users, so it was with great anticipation and excitement that we watched the WWDC Keynote and other WWDC talks this week. Here are a couple things that especially caught our eye.
This was a welcome surprise. If the online buzz is anything to go by, it has been enthusiastically received by most of the developer community. In our own excitement, we have already developed an in-house build of a Splitforce module for our iOS customers that works perfectly with Swift. Unfortunately, we cannot currently release it due to the NDA terms; but rest assured, it will be ready as soon as the terms are lifted. Registered Apple developers who don’t want to wait can contact us for early access to the new module.
Swift is designed to ‘achieve results faster’ and to that end, Apple has designed a syntax that deftly balances succinctness with clarity. While there is automatic bridging from our existing Objective-C API to Swift, we love elegant code so much that we started working on a new Swift-inspired API for Splitforce that will help our customers achieve results faster. To whet your appetite for what’s possible, take a look at the following snippet:
var sf = SFManager(applicationId: <#appId#>,
button.setTitle(“Okay”, forState: UIControlStateNormal)
view.backgroundColor = UIColor.blackColor()
button.setTitle(string, forState: UIControlStateNormal)
view.backgroundColor = color
A clean, lean, A/B machine! The first parameter identifies which experiment you’re running, the ‘whenDefault’ named parameter covers the base case for when the user is receiving the default variation, and the tail-closure format cuts out extra typing and clutter – providing your closure with a SFVariation object. Adding some convenience methods to SFVariation permits a clean interface where we unwrap the contents and only call your closure when the parameter exists, logging a warning if the parameter is not part of the variation. This is only a first cut – we’re looking at further possibilities with Generics and Subscripts to get this even leaner!
Developers practically live in the debugger and the documentation – especially when adopting a new technology or framework. In this context, the Playground is a really powerful construct for experimentation that accelerates the development cycle by cutting out the Build->Test->Debug->Fix cycle, replacing it with a simple Read->Eval loop that enables you to really get to grips with your objects and frameworks. Not only is this a boon for anyone picking up the Swift language, it’s also great for users looking to get the most out of Splitforce. We already have the Framework running inside Playground, and with a couple of helper functions to handle the different RunLoop model inside Playground, we’re all set to experiment with experiments! We added QuickLook support in an earlier version of the Framework, and this really helps now we have Playground giving us a nice clean view of:
Debug Mode: OFF
Number of Experiments: 1
Number of Variations: 2
Variation Name: A
Experiment Name: Swift Test
swiftColor = “#f50f39″;
testSwift = “I’m Swift A”;
} SFManager and SFVariation objects:
QuickLook offers a lot of potential to provide a clear view of what Splitforce is doing, giving you clarity and confidence, and making it super easy to ensure you have your experiments set up just right. We’re planning a range of features that will use this power, but it would be great to hear some input on what you would value most. Ideas on our whiteboard currently include:
Segmentation Switches – match your playground environment to the segments defined in the Splitforce dashboard
Variation Gallery – see all valid variation data within Playground
ExperimentMap – map your experiment closure across all variations to compare the results side by side, ensuring every variation is set up correctly
Reset Runtime – reset the runtime environment to sync with the latest data from Splitforce
The acquisition of TestFlight gave Apple a strong response to critics of the AdHoc build process. While TestFlight on its own was a tremendous time saving and client-pleasing tool, it’s even better under Apple’s control. Each app can now have up to 1000 beta users, and each user can use it on multiple devices. This is great for optimising your applications with early adopters.
At Splitforce, we’re looking at ways to separate your early adopter metrics from your complete user base’s metrics. This way you get plenty of insight and optimisation opportunities from your early adopters before you go live, while keeping your wider user base metrics clean. We’ll have more details and best practice recommendations once we’ve had more time to play with the new TestFlight, but we’re excited and hope you are too!
Interactive Notifications & Extensions
To ensure you have the best opportunities for optimisation, effective measurement is critical at all parts of your customer journey. With Interactive Notifications, there are now more entry points into your application, and more interactions that can and should be measured. We’ll be looking into the details and making recommendations on how best to integrate with this soon.
Help us help you!
This has no doubt been a good WWDC for the Developer Community and there were a ton of other interesting developments announced, including the release of Yosemite, Continuity, and Resizable emulators.
We have a lot of ideas spinning around internally, but would love to get your feedback, ideas and priorities. Your insights continue to help us make the product even better. Please let us know which areas you are most interested in so we can support your goals as they evolve.