Showing posts with label ios. Show all posts
Showing posts with label ios. Show all posts

Thursday, 17 March 2016

Mobile@Scale 2016

Last month Facebook invited mobile developers into their London offices for a collaborative discussion on scaling mobile development.

The focus was mainly on native development — and the attendees were mostly iOS and Android developers — but the scope expanded to include scaling development processes as well as how to scale apps for lots of users.

Jim Purbrick @JimPurbrick, Engineering Manager in Facebook London’s office, introduced the talks by saying that on mobile, the bug stakes are higher — once a bug is released, the app is on people’s phones and is much harder to fix. You can’t just update the code and see people get the fix in the next page refresh.

And for all the focus on ending up with a native app in the platform-specific app store, two of the big themes were sharing code across platforms and being able to make quick changes to apps that were already deployed.

I was impressed by the inclusivity of the conference — not only were the speakers from a variety of companies (not just Facebook or Facebook partners) but the audience were encouraged and given time to ask questions and discuss with the speakers.

The talks and discussions were all videoed and I’ve linked to them below together with my notes highlighting the points that made an impression on me.

Scaling iOS @ Google

Michele Aiello @micheleaiello, Tech Lead Manager on the Calendar app, Google

Michele gave a really detailed talk about how the iOS teams at Google deal with handling large amounts of code shared amongst many geographically spread developers. There’s lots of useful nuggets in here — and it’s interesting to see where Google have invested time and effort in order to make cross-platform and large team development easier.

Scaling iOS @ Google - Michele Aiello

Posted by At Scale on Monday, 28 March 2016
  • Google has more than 60 apps in the Apple App Store!
  • iOS devs have moved from London to every office worldwide
  • strategy on how to share code really important
  • design & ease of use crucial for scaling apps
  • yearly gathering of all mobile developers
    • often start shared efforts there
  • regular tech talks in local offices + recorded & streamed around the world
  • have feature specific “Tiger teams”
    • one goal: ship a feature
    • cross functional: Android, iOS, web, PM, UX, API, etc
  • have trouble with merging & reviewing xib, project & storyboard files
    • so Chrome team developed GYP: JSON for structure & dependencies
    • GYP: “generate your project”
    • use storyboard & xibs for prototyping, then shared code for elements
  • release management:
    • regular releases every 2-6 weeks
    • with feature flags to toggle new features
    • compile time flag during initial dev, then runtime flags for later
    • known as the release train
    • heavier-weight trains need synchronising with marketing etc — ok to be a little late
    • 75%-80% of users are using auto-update so automatically get updates
  • testing:
    • XCTests for functional and performance
    • KIF & Earl Grey for UI tests
  • sharing code
    • single repo
    • HEAD is always stable
    • all code is available and shared
    • making a change in shared code: see the test results and roll back if issues
  • for any shared code
    • enforce documentation & example code
    • catalog app for UI elements
  • for cross platform sharing
    • try to share model cross platform and to server too
    • makes offline easier
    • have tried webviews & javascript
    • now using C++ & J2ObjC
      • C++ easy on iOS, complicated on Android
      • used in Chrome
      • j2ObjC used for Inbox
    • j2ObjC even lets you debug into transpiled Java code in Xcode
      • breakpoints, stepping, variable values all work
    • if code is simple, look at sharing the tests rather than the code
  • swift at Google: currently playing with it
    • have found that development is faster
    • probably waiting a few months to bring into production apps
  • user testing using beta releases (testflight, android beta)
    • metrics in the app
    • surveys after testing
  • have tools to search whole repo to find out if code is still used
  • sharing layout
    • done using sharing layout logic

When mobile IDEs need to scale

Al Sutton @AlSutton, Facebook

Al talked about how Facebook builds Android apps, and how they feed back improvements to their build process into the open source community (e.g. IntelliJ community edition and the Buck build tool). By using Buck, they allow their developers to choose whatever IDE they want.

Nuclide

James Pearce @JamesPearce, Head of Open Source at Facebook

James continued from Al’s Android introduction to talk about Facebook’s new Nuclide IDE for building iOS apps… It’s exciting to see some competition in the iOS IDE world — whilst Xcode is great at some things, it often leaves a lot to be desired. JetBrains’ AppCode is a useful challenger but to have an extensible open-source IDE for iOS could be a game changer. The only downside for me is that Nuclide relies on Buck, so you have to change your project to buy in to the Facebook toolchain. Perhaps if someone could create a Fastlane plug-in…?

  • unlike IntelliJ, Xcode is not open source, so can’t contribute
  • existential issue for Facebook…
  • started extending Atom from github
  • aded Flow, Babel, Clang & Buck
  • created Nuclide
  • also added Chromium dev tools to help debug into app
    • lets you debug into Javascript, Objective C, etc all in same place
    • transpiling keeps source maps to help with line numbers
    • also lets you inspect into UI hierarchy for ReactNative apps
    • includes highlighting
  • now have 2/3rds of committing engineers using Nuclide
  • have analytics built-in
    • tracking feature usage
  • internal infrastructure team has become a product team
  • now available at http://nuclide.io
    • analytics kept for internal
  • other open source projects
    • pop: iOS animation library
  • doesn’t have refactoring yet

6 lessons learned scaling mobile at SoundCloud

Next up were a couple of sessions from smaller companies (though still not small!) showing how they built and adapted their apps faster to keep up with demand. SoundCloud spoke about using ReactNative (more on that later) and how they structured their dev teams to include mobile developers.

Jamie McDonald (Android) @jdamcd & Matej Balatic (iOS) @skavt, SoundCloud

  • building out new SoundCloud Pulse app for people creating sounds
  • most engineers busy on main SoundCloud listener app
  • got a partner for Android, but built iOS app with ReactNative using web developers
  • shared design & feature set across platforms saves a lot of time
    • were previously designing features twice
    • marketing was more complex too
  • mobile specific API
    • mobile-specific features: background sync, batch fetches
    • “back-end for front-end” idea from ThoughtWorks
  • developed C-based mobile playback library (skippy)
    • initially for Android, now rolled out across iOS too
    • e.g. optimise streaming for emerging markets
  • tried to spread mobile devs through feature teams
    • but spread too thinly
    • weren’t able to pair and share knowledge
  • instead created clusters of feature teams
    • mobile engineers shared amongst each cluster
    • could be in enough numbers together
  • release train model
    • each feature team can take responsibility for shipping
    • allowed action but also feedback and responsibility
    • use feature flags — team responsible for turning on when ready
  • tools used:
    • iOS:
      • FlipTheSwitch
      • stable CoreData stack — specific use of framework
    • Android, use LightCycle (soon to be open-sourced)
      • forward life cycle events to small independent modules
      • receives callbacks but doesn’t need to know which activity its attached to
      • enables better unit tests as can separate things out more effectively

Backend-driven native UIs

John Sundell @johnsundell, iOS Developer, Spotify

Spotify have an almost completely content-based app and are constantly tweaking to change the presentation and priority of different music. John and his team came up with a way of handling that change by controlling the whole app UI from the backend API.

  • define components in backend API
  • generalised data binding
  • generalised components
    • implement standardised components which can be picked up from API
  • can put cacheing, and lots of standard stuff in the generalised app
  • control the UI from the backend
    • API contains view models rather than raw models
  • Ed.: makes sense if you have an app with lots of similar components
    • especially for a content-based app
    • similar to Google’s code-based component library
  • were able to delete 20,000 lines of code on home page browse view
  • overall have been able to delete 100K lines of code across iOS & Android
  • use layout traits to control layout
    • e.g. full width, separator, stackable
  • request sends a lot of data about the device to the backend
    • can return different components & layout depending on device or screen size etc
    • sometimes send extra data in response so can handle quick changes e.g. screen rotation
  • support infinite scroll using metadata with URIs for follow-up pages
  • can set up fallback components — if this not available, fallback to previous
    • enables playing around with new features & UI but still supporting older builds

Infer: Moving fast with static analysis

Dulma Churchill, Software Engineer, Facebook

Taking up Jim Purbrick’s challenge of dealing with the higher stakes of bugs in mobile, Dulma gave us an introduction to Infer — Facebook’s static analyzer that can check for memory and resource leaks and null pointer issues each time you compile.

  • static analyzer that doesn’t require pre/post conditions
  • compositional, so doesn’t need to process whole project at once
  • very intertwined with compiler
  • infer can find inter-procedural bugs not local to single file
  • used with CI can be set up to only process newly compiled files
  • within facebook: fix rate around 70% in recent months
    • high rate due to getting results on continuous integration
  • there’s an Xcode plugin
  • integrated with codeboard
    • web-based IDE to teach programming in classroom
    • Java, Python Haskell…
  • see their blog post about being used at Spotify

3000 images per second

Henna Kermani @tokyotwilight, Software Developer, Twitter

Some interesting stats from Twitter here, in Henna’s story of how Twitter scaled up their image and video handling.

3000 images per second - Henna Kermani

Posted by At Scale on Monday, 28 March 2016
  • image uploading used to be all in the same API call as the tweet itself
    • any point of failure would fail whole thing
    • waste of bandwidth for client & server
  • split out image upload from tweet content
    • also allowed segmented, resumable uploads
    • used multi-part POST requests with separate INIT, APPEND & FINALIZE API calls
    • massive drop in upload failures, especially in developing world
  • did research on age of images:
    • 15 days 50th percentile
    • 150 days 90th percentile
  • so kept original + 20 days of variants
    • balance between storage increase per day and computation on each request
    • saved $6m in 2015 just from this change!
  • image formats
    • tried using WebP for 6 months last year in Android app
      • ~25% smaller than PNG or JPG — better engagement
      • but not supported on Android <4 or iOS…
    • converging on progressive JPEG instead
    • used Facebook’s Fresco library in Android app

React Native

Pieter De Baets @javache, Facebook

Pieter gave a detailed intro to React Native — building native apps for iOS and Android using just JavaScript and HTML-like markup.

  • if you ship a bug in a mobile app, there will always be a user out there running that bug — no matter how many updates you apply…
  • write UI declaratively, code in Javascript
  • share lots of code between iOS and Android
  • Apple’s guidelines don’t allow you to update code in a running app
    • but there’s an exception that lets you update JavaScript over the air
    • so you can update React Native apps instantly

Don’t forget the web

Jeremy Keith @adactio, Founder, Clearleft

After all that talk of native development, Jeremy brought us back to thinking about the web and how it will always be the largest, widest target. It isn’t a “platform” and it will never be the leading edge of mobile, but it is for everybody.

Don’t forget the web - Jeremy Keith

Posted by At Scale on Monday, 28 March 2016
  • when building for the web
    • start with core functionality
    • implement with simplest techology
    • enhance!
  • can be done for whole service but also for individual components
  • Ed. is this that much different from native?
    • especially for different OS levels, Android features etc
  • there’s always something new that’s not fully supported

Saturday, 28 September 2013

Over The Air 2013

Building an Internet of Things for Everyone

Alexandra Deschamps-Sonsino https://twitter.com/iotwatch

  • get the work you want
  • if you get work just for money, you’ll get more of it
  • won’t get you the work you want…

good night lamp

  • originally in 2007 people were unsure about it
    • it uses Wi-Fi: isn’t that a health risk?
  • restarted in 2010 — no longer a problem

IoT is now accessible

  • hardware & software is easily available, documented + supported with lots of forums
  • lots of hackspaces around to make thing
  • idea to making something that looks pretty and works: “I give you 2 weeks — and 1 of those is waiting for things to be delivered”
  • still hard to get something to production scaling, but getting support for that:
    • Fritzing, DesignSpark, etc

IoT vs big business

  • wanting to bridge concerns of small business and large corporations
  • both want the same reach of
  • standards & security
  • british gas https://twitter.com/connectinghomes & #connectinghomes 26/09/13
    • 25 startups in energy sector
    • bobo the polar bear: changes colour depending on how you manage your home energy
  • need to get corporates who are interested to actually meet the people who are doing stuff

Telling the right story

  • journalists will make stuff up…
  • make sure you tell a good story
  • e.g. onesie for a child with sensors
    • great for children with health conditions
    • but could be creepy for parents
  • you have to be completely clear about why a customer would want to buy what you’ve made
    • create a press release and a dropbox full of well-lit, decent pictures

Investment

  • investors < 60 years old will probably have never invested in anything other than the web…
  • they need to see more hardware things
  • new https://twitter.com/bg_ventures incubator

Retail is interested…

Building Complex Web Apps with Dart & Web Components

Chris Buckett https://twitter.com/chrisbuckett

  • V8 is as fast as they can get for javascript
  • dart is faster for some benchmarks already

dart language

  • optionally typed
    • when Dart runs, it pays no attention to the type information
    • use types for annotations
    • used for communication and validation
  • classes are also interfaces…
    • like duck typing
  • has privacy: just prefix with underscore
    • also has package shared equivalent
  • concurrency & async support
    • works with web workers in the browser
  • supports libraries by default
    • a single repository of libraries
  • built-in support for DOM
  • DartDoc is markdown based :-)
  • Dart VM not in any browser other than Dartium (special Chrome build)
    • but has been designed to compile to javascript
  • the language is still a beta, some restrictions
    • e.g. can’t modify variables on the fly

web components

  • Polymer is Google’s implementation of web components
  • polymer.dart is the dart version
  • polymer elements consist of a template & a script
  • elements get created and added to the shadow DOM
  • polymer elements have double-barrelled names
    • first part is namespace
    • hyphen is mandatory

Designing for diversity

or How to stop worrying and deal with Android fragmentation

Stephanie Rieger

a bit of history

  • port of leith, edinburgh: cruise ships stop
    • crew come out and use the internet
    • mostly filipino (25% of crew are filipino)
  • massive change in devices in a short time:
    • 2010: massive laptops
    • 2011: netbooks
    • 2012/13: tablets/phablets
  • and this is a change for people who send most of their income home
  • mobile phones were getting smaller, but needed large teams
  • started to change in 2005:
    • mediatek started offering reference design chipsets
  • went from giant companies to tiny ones
  • lots competed on price, but others went with regional specializations
  • by 2007, these had captured c.10% of global device sales
  • started experimenting wildly
    • e.g. 4 SIM phone with a project
    • could try out with tiny production runs
  • then Android changed things again in 2008
  • these companies could now switch from low-end feature phones to mid & high range
    • e.g. Lumia lookalike, running skinned Android, sells for £56!
  • other chipset vendors have emulated MediaTek reference designs
    • e.g. Rockchip, even Qualcomm
  • all the components are now tuned to work with Android by default

hardware diversity

  • variations at different levels
  • low-end: all off-the-shelf — around £56
  • slightly more customized: nice case, slightly customised Android, off-the-shelf chip
    • e.g. Xiaomi Hongmi
    • dual SIM, gorilla glass, highly customised Android (MIUI)
    • just £83
    • sold out first batch of 100,000 in 90 seconds…
  • we’re used to having customisation all the way down
  • but even larger companies are experimenting
  • Japan - KDDI Infobar: highly customised design & Android
    • fashion product
  • Oppo: Bluetooth LE camera trigger, touch panel on rear of phone
  • Yota e-paper rear display: can retain image for weeks without power
    • also has a capacitative touch strip
  • India: Aakash 2 is now c.£30
    • govt aiming to subsidise & distribute to 20 million students
  • it’s increasingly likely that devices will be made by “other manufacturers”

platform diversity

  • Android lets you change the keyboard
  • as a developer you can’t rely on the user having a standard keyboard
  • also lets you change the default app for intents
  • Paranoid Android lets you change the resolution of the device at the app level
    • as apps adjust to resolution & screen size, this lets you choose the way the app behaves on your device
  • MIUI is particular popular as it’s actively crowd-sourced
    • also because there are thousands of community build themes
    • including metaphor-based themes with virtual navigation
  • Oppo now lets you choose your ROM when you order your phone: Oppo’s Color or CyanogenMod
  • Cyanogen aiming to create a one-click installer
  • manufacturers are supposed to include the default Holo theme
    • but some small manufacturers don’t
  • manufacturers will also select OS versions and not update for a while
    • we will always see multiple versions live at any time
  • also multiple app stores especially in different countries
  • unofficial app store booths (e.g. in a Bangkok mall)
    • owner will recommend and install apps for you

how do we design for this?

  • design strategies will apply to Android IoT devices as well
  • basic principles:
    1. be flexible
    2. provide assets for all
    3. optimize layouts
    4. enable diverse experiences
  • can use weighting to scale cleverly
  • use asset grouping to enable variation
  • google publish screen density stats every 2-4 weeks
  • as screen gets bigger, letting the UI stretch doesn’t work so well
  • very similar to responsive design
  • set breakpoints in your layout where you change layout
  • want to avoid have three versions that you swap
  • instead aim for a continuum where content adjusts itself
  • Evernote is a good example
    • list view switches to grid view on larger screens
  • see also Google IO & Wordpress apps
    • Wordpress portrait tablet has list and detail side by side
  • lots of qualifiers
    • touch screen type: capacitative/trackball/finger
    • UI mode: car/desk/television/appliance!
  • not necessary to account for all combinations!
  • enabling intents allows future-friendly behaviour
    • don’t have to worry about new social networks in different countries
  • official android devices reached 1 billion last week
    • doesn’t include non-Google devices
    • probably doesn’t include cars, etc
    • doesn’t include experimental Android IoT devices

“diversity is not a bug, it’s a feature”

Arduino: Robots, WiFi and extreme hacks

David Cuartielles https://twitter.com/dcuartielles

  • based in Malmö Uni
  • all got into Arduino because wanted something for students
  • “as technology grows in our hearts, it gets smaller in size”
  • David’s background: worked at Infineon designing chips, then went to teach technology to arts students in Sweden
  • had six months to teach people to program
    • had to relearn how to learn
  • arduino not just boards:
    • boards
    • dev tools
    • documentation & community
  • not teaching about transistors: teaching how to make a light blink
  • arduino ide doesn’t have lots of features
    • but gives you feeling that you’re in a slimmed down version of Eclipse
  • short run manufacturing (c.10K) so can always change the design
  • hacked a full-sized car to be remote controlled
    • will see self-driving car on youtube soon…
  • in mexico city only room for 30% of students in university
  • instead they have arts centres for students who don’t get it
  • David taught electronics there:
    • sorted out electronics sourced from mexico as components not available
    • vimeo: ohoh robochock
    • vimeo: ohoh competition
      • trying to remote control their robotos
      • all interfering with same channel, but they don’t know!
  • arduino robot
    • designed with help from kids from mexico
    • 4 times winners of robocup
    • invested a lot of time in the AC/DC converter
    • so that performance is consistent across battery
  • educational experiment in Spain
    • 24 schools, over 500 kids (15 year-olds)
    • every week had three sessions: introduction, hacking, sharing
    • each week was thematic: e.g. sports
    • 25 kids, 5 projects: olympic games on Friday
    • 24 different experiments, but kids didn’t do everything
    • instead saw what other kids were doing
    • all details http://cuartielles.com/verkstad/en
  • hacked Sony SmartWatch to run Arduino
    • all published on github: underverg?
    • only thing couldn’t get hold of was bluetooth chip
  • natural fuse
    • plant lives or dies based on your carbon footprint
    • if it dies your electricity stops
    • can switch between selfish (grab from neighbours) and selfless (offer spare to neighbours) modes
  • fukushima
    • pachube/cosm was used for people to map the radiation themselves
    • using arduinos with geiger counters
  • open source white goods controller
    • modular: only need four abilities
    • mosfet, relay, pwr, ??
    • added UI module to provide output
  • everything is open source
    • pay me to make it: once it’s made, the work is done
    • you can pay me to maintain it

Whitespace Networks: Connect All The Things

Ben Ward https://twitter.com/crouchingbadger - http://love-hz.com

  • TV whitespace becoming available as moves from analogue to digital
  • however, will still be used for analogue radio mics etc
    • if we cock up they’ve got lots of famous people to complain!
  • weightless protocol)
    • 10 yr battery life
    • 5-10km range
    • unhelpfully called “super-wifi” in america (802.11AF)
  • needs a whitespace database…
    • being worked on right now
    • need to check every 15 minutes
    • check OFCOM for list of approved DBs
    • then check with your licensed DB
    • but you’re not reserving space, just agreeing to share
    • see also http://uk-whitespaces.spectrumbridge.com
  • neul now making a 4.5cm2 board
    • expected price $17 (at scale)
    • range: 1-8km
  • new phrase: “the fog” — like the cloud but on the ground :-)
  • open source boards
    • using software defined radio chip (lime something)
    • myriad RF
    • nuand bladeRF
    • also hackRF?
  • has some location capabilities based on triangulation
  • ideas?
    • bike theft detector using the frame as the antenna
    • oxford guerilla sensor network for flood detection

Appium: Mobile Automation Made Awesome

Jonathan Lipps https://twitter.com/jlipps

  • cross-platform solution for native & hybrid mobile automation
  • other options for ios:
    • calabash-ios
    • Frank
    • ios-driver
    • UIAutomation
    • KeepItFunctional
  • other options for android:
    • calabash-android
    • MonkeyTalk
    • Robotium
    • UiAutomator
    • selendroid
  • wanted to set some ground rules:
    • test the same app you submit to the store
      • don’t want to add additional code into the app
    • write your tests in any language & framework
    • use a standard automation API & spec
    • make it open source and foster a large community
  • appium supports:
    • ios, android & firefox os
    • real devices, simulators
    • native apps, hybrids, mobile web
  • can write one set of tests that work across multiple platforms
    • if you’re careful in how you structure your app
  • appium exposes an HTTP server than allows selenium to run
  • selenium webdriver has clients in many languages
  • and is a W3C working draft, so nearly a standard :-)
  • appium also extends webdriver protocol with additional mobile-specific behaviours
    • talking to selenium to get those changes into
  • under the hood:
    • iOS: Apple Instruments & UIAutomation
    • Android 4.2.1 and up: Google UiAutomator
    • older Android + hybrid: Selendroid
    • Firefox OS: marionette
  • written in node.js, so npm install appium and write tests in node
  • or else have a GUI runner to set flags
  • GUI also comes with an inspector
    • so you can see what’s going on at each step
    • (don’t need to be the app developer to write a test)
    • will create some initial code for you from your actions
  • find things by:
    • accessibility
    • element type
    • hiearchy xpath
    • android id
  • you can use a config dictionary for IDs/xpaths to help cope with platform/device differences
  • instruments can only run a single test at once per host machine
  • Sauce Labs have lots of devices available across the net

    • provides scaling and device selection
    • can switch to Sauce just by changing appium end point + adding credentials
    • also need to provide app: pre-upload using Sauce API, or host on a server somewhere
    • http://saucelabs.com/mobile
  • Q: can you switch between apps?

    • we could use a second app to turn on/off wifi
    • A: doesn’t work on iOS — when you jump to another app then UIAutomation loses its context and quits
  • Q: can you fake location?

Programming is terrible

Lessons from a life wasted

Tef https://twitter.com/tef

  • Watch out for The Group Project: getting together to work on a project that individuals have not made time for themselves…
  • make your code easy to replace more than easy to extend
  • people often learn more from maintenance than from building from new
  • people tend to teach in the way that they learned best
  • C, Java, C# are not a great starting point for new programmers
    • they require concepts to figure out even before you can make things happen
  • learning programming should be a side effect of doing something exciting
  • girl at MIT struggling with English grammar
    • Seymour Papert asked her to write a sentence or poetry generating programme
    • after a few hours, she exclaimed “I know what nouns are!”
  • view source
    • one of the best features of Scratch online
    • learn by seeing something you want to copy
  • computer anonymous
    • support group for everyone
  • for a starter, introduce constraints if they’re not already there

Tuesday, 16 July 2013

MomoLondon: Operating Systems – a new set of Davids take on the incumbent Goliaths

Some really useful insights this week — with the panel providing a different perspective on the mobile industry than the usual. Although one question started on the HTML vs Native war, this was quickly knocked on the head and left for a future Mobile Monday.

I really get the FirefoxOS aim of making the web more accessible to new markets around the world. Mozilla has its own motivations for making a new OS, which are different to the usual “make as much money as possible”. It will be very interesting to see how they compete against the low-cost Android devices that are getting cheaper every year.

As for Ubuntu Phone & Tablet, this seems to be more about an operator story than a consumer one. I’m not sure of the reasons why a developer or a consumer would choose an Ubuntu phone. Having played with the sample tablets that were available on the night, I couldn’t see any particular advantages over Android or iOS (or Blackberry or Windows for that matter).

Ubuntu’s message seems to be that operators can customise the devices for their own content (that always goes down well with consumers, not!), or that you can have a single superphone that you can plug in to a screen and get a desktop experience (seems like a bit of a gimmick to me…).

Thanks to Geoff Blaber for being an excellent chair and keeping the discussion moving fluidly, and to all the panel members and organisers for a great evening.

Intro

Victor Palau, VP of Phone & Hyperscale Delivery at Canonical

  • hardware & os market has become monopolized in last few years
  • standardization on Linux kernel (mainly from Android) makes it much quicker to set up a new operating system
    • don’t have to worry about chipsets etc as much as in Symbian days
  • but platforms have to have something

Developer Economics Q3 2013

Andreas Constantinou, MD at Vision Mobile

  • launching latest research today
  • Ed.: this is always a really good read — Andreas gave us some highlights, but go and download the full report at http://www.developereconomics.com/go
  • html5 is number 3 development platform in use
    • Android leads, then iOS, everything else way behind
  • 61% of html is direct to browser
    • then phonegap at 27%
  • Windows Phone going down in intent share (i.e. less developers interested…)
  • iOS still leading monthly revenue at $5,200
    • Android catching up at $4,700 (using in-app advertising as main booster)
    • revenue models differ by platform
  • seeing an increase in platforms used by individual developers
  • main platform almost even between Android (34.4%) and iOS (32.7%)
    • html5 behind at 17.5%
  • report trying to quantify platform loyalty amongst devs
  • also trying to show which platforms are best for different challenges
    • and the different motivations for different developers
  • more experienced developers are using more tools
    • e.g. crash reporting, ad networks, push notifications

Panel

  • Geoff Blaber @geoffblaber
    • CCS Insight research house
  • Alex Sinclair, CTO of GSMA
  • David Wood @dw
    • principal at Delta Wisdom, formerly prime mover behind Symbian
  • Andreas Constantinou @andreascon
    • MD at Vision Mobile
  • Victor Palau @victorpalau
    • VP of Phone & Hyperscale Delivery at Canonical
  • Christian Heilman @codepo8
    • Principal Developer Evangelist (HTML5/Open Web) at Mozilla

What do new platforms offer manufacturers?

  • GB: essentially just 2 OEMs (Apple, Samsung) making any profit
  • CH: not a problem of distribution but where it is going
    • producing lots of phones in saturated market
    • Mozilla’s job is to keep the web open
    • the web is worldwide
    • FirefoxOS is targeting markets that mostly have featurephones, aiming to be people’s first smartphone
    • you can get old Androids but they’re 4 generations behind with old browsers that don’t show stuff right
    • manufacturers actually quite interested in this proposition
    • Foxconn hiring 3,000 people to make a FirefoxOS tablet
    • Samsung & Apple neutering open web — you need expensive hardware and a credit card to be a part of it
    • in Spain selling €79 phone with €30 pre-paid credit
  • GB: open initiatives have failed in the past: WAC, etc
  • VP: open initiatives can have trouble with leadership
    • Canonical remain open but have strong leadership
    • offering operators ability to showcase their content
  • DW: two good cases for disruption
    • companies that have shown their staying power
    • just an improvement in battery life would be welcomed…
    • smartphones naturally get stretched as new environments come along — and leave space for niches

What about the ecosystem?

  • AC: for any platform to be successful need buy in from:
    • developers, operators, manufacturers, users, …
    • devs have to learn new platform
    • users don’t care what’s underneath
    • operators have pre-allocated slots, often by OS
  • CH: Windows Phone is a great example
    • not seen the depth of commitment required from the operators
    • not willing to take the risk
  • AS: not all operators subsidise handsets
    • when a new version of the iPhone comes out, AT&T’s share price drops as they have to subsidise it
    • need an alternative
    • different operators placing different bets
  • AS: operators want to get their content onto devices
    • but are struggling to do so with iOS & Android
  • Ed.: this is probably one reason why those two are doing so well!
  • CH: app discovery as easy as searching
    • search for a movie: get IMDB deep link
    • go back to search and long-press to install app
    • then get offline goodness etc
    • drives me crazy that I have to wait 5 months for a game my friend is playing on his different device

What about the corporate sector or 3rd sector (training & education)?

  • VP: one of our main focuses at Ubuntu
    • have a very secure platform, bringing to phone
    • converged device — plug in your phone and get full desktop
    • good for enterprise: single device, secure
  • CH: enterprise difficult to get into as wedded to Blackberry or other platform that’s integrated with email system
    • difficult sell for open source
    • 3rd sector is an easier sell
    • e.g. simplified phone for elderly: just photos of family — click to call
  • AC: changing the UI of the phone reminded me of SavaJe (way back in 2006, bought and swallowed by Sun)
    • html5 is top platform for enterprise
    • top driver is efficiency
  • CH: developer scarcity — don’t have to go out to an agency
    • just use existing web team
  • DW: enterprise can drive home usage too
    • LinkedIn most popular enterprise app?
      • switched back to native on mobile as tools were not good enough
  • AC: html5 apps are like a car without a break
    • once it starts leaking, you can’t stop it

Are you seeing apps migrating from mobile to desktop?

  • DW: more about device usage — consumer behaviour is leading
  • VP: end of Windows XP support is great: making people think about it
    • at the moment can’t replace them with an html5 app
    • but solutions available in Ubuntu
  • AC: crawled the Google store to find APIs used
    • only 1 in 4 Android apps could be done on straight web
  • CH: that’s why Firefox provides access to device
    • some memory leaks come from platforms they are using to generate code
    • Chrome and Firefox dev tools making great strides

How many years are going to pass before clients say “don’t do native”?

  • VP: has to be lots more about what’s good for consumer
    • depends on the situation and who you’re aiming it at
  • AC: it’s not an either or…

Privacy: number one for Mozilla / chinese walls between work & home

  • AS: virtualisation of phones available: multiple phones in one
    • lots of companies don’t use Dropbox for security reasons
    • don’t think about all the data that certain closed OSes are capturing about us
  • DW: trustworthy and transparency may be change reasons
  • CH: already seeing that for Firefox browser
    • sometimes have to make the UX harder to make people think about what they are doing
  • VP: full Linux implementation
  • GB: isn’t there an argument that deep integration with Google is part of Android’s success?
  • AC: people don’t ask if Facebook & Google are spying on them: they give you something back which you perceive to be of value
  • CH: it’s actually more addiction than value…

What positive reasons for getting new platforms?

  • AS: it comes down to competition
    • is it a good idea for just a few companies to make the profits?
    • I represent people who used to make the profits from the industry…
    • was previously director of WAC, but by the time it was ready there was no need for it as only two platforms to develop for
    • operators want to implement RCS/joyn (operator-based IP messaging, voice, video, etc) and new platforms give them the chance to get involved
  • DW: so many variations
    • e.g. Nokia mega pixel camera: “average user only cares 16/23 about camera pixels” — but actually there’s a reasonable niche here

What about the important services that users expect?

  • e.g. Skype, Google Maps
  • AS: was in Korea last week: their search provider is being investigated for monopolistic practices
    • also a messaging provider was worried about operators implementing RCS/joyn and taking away their revenue stream
  • CH: service in China to add “written on an iPad” to the bottom of your email
    • $5 a month, and they stole your email data!

What about individual permissions?

  • CH: permissions can be asked on a more granular basis
    • no great list of permissions as for Android
  • AC: how much would you be willing to pay for a service that monitored and reported how your private data was being used?
    • people want it but are not willing to pay for it

Who is likely to nudge sub-saharan Africa into smartphones

  • full of featurephones
  • OLPC not doing that well
  • CH: OLPC didn’t do so well as missing network connectivity
    • Ushahidi is building a wireless BRCK to be a modem for Africa
    • if someone asks “what if Google or Apple go after these markets after you”, answer is “then we’ve won!”

Visiting from Momolo Nigeria: what difference will a billion users in Africa have on design considerations?

  • 120million mobile phones, mainly featurephones
  • CH: sent UX designers to South America to come up with use cases
    • build apps with Telefonica targeted at those markets
    • need to meet somebody local who knows the area
    • can’t assume that everybody wants the same thing
  • VP: community is very important
    • a lot of people in Africa want to contribute and make things better for their community
    • have a whole set of local community councils
    • e.g. large Catalonian community
  • AC: if you need to access the internet you need a data plan
    • developing countries have very expensive access plans
    • need to have smarter ways of micro-access to the internet
  • DW: designing meaningful UI for people who can’t read or write
  • AS: some operators already doing micro data plans
    • e.g. facebook access not coming out of data plan (facebook zero)

Closing remarks

  • GB: often on West Coast of US, it’s Android, iOS or the highway
    • been impressed that there’s a great strength in the alternatives
    • barriers to entry getting lower
    • html5 provides common access
    • market driven by growing diversity
    • fragmentation in OS space is likely to proliferate
  • AC: there is no black or white
    • there’s always multiple alternatives
  • AS: there’s a definite need & opportunity
    • don’t know who is going to win
  • DW: which David will survive?
    • execution: can the company keep pushing out high quality?
    • proposition: will people bit?
    • community: can they start a virtuous cycle?
  • VP: can you get a consumer to buy something different?
  • CH: there’ll be a lot of opportunity for a lot of players
    • we were the only cool thing in MWC twice in one day
    • device should not spy on you: built the internet in a different idea and this should exist on mobile phones too

Announcements

Tuesday, 5 March 2013

NSConference 5: Day Two

Thriving in an App Store World

Michael Jurewitz @jury

Jury used to be an Apple Developer Evangelist. He is now Director of Product Development at Black Pixel.

work well with apple

  • need to be looking forward - focusing on future (tech/features/hardware)
  • stay on the radar of apple contacts
  • Apple looks at devrel as “animal husbandry” :-)
    • Apple wants to sell devices & make customers happy
    • so apps should feed into that
  • Apple has laser focus on future and simplicity
    • expecting & embracing change
    • they force themselves to keep going forward
    • won’t look at apps that don’t fit in to that
    • must stay current
  • no secret agenda, but often hard choices
  • can get featured by taking advantage of new OS features
    • but it’s a time limited offer…
  • example:
    • Eventbrite getting featured on Passbook feature page increased new user sign up by 664%…
    • got in right at the beginning – only 15 apps on the feature page
  • “if users aren’t upgrading their OS, they probably aren’t buying your software either” - Wil Shipley
  • Gatekeeper vs App Store: e.g. Kaleidoscope
    • if you buy Kaleidoscope on Mac App Store then you can also download direct
    • app will notice that it’s already been purchased
    • will check receipt and unlock automatically
    • useful for sending customers beta builds when testing fixes
  • file bugs
    • also for requesting to open APIs that are currently private
  • localisation:
    • Apple sales in China increased 400% last year
    • Germany has a strong software market, even though it’s limited in size
  • accessibility creates loyalty

properly value your work

  • Jury did some research over the past weeks…
  • top paid apps have much lower mean & median prices than top grossing apps
    • mean: paid $12.46 vs grossing $49.13
    • median: paid $6.99 vs grossing $29.99
  • two separate markets going on here
  • top grossing has:
    • 200% more Finance apps in top grossing at the moment
      • because it’s tax season at the moment in the US
    • Utilities drop by 25%
    • 22% more Games
    • 50% more Graphics
    • Social drops in half (and would be nothing without Tweetbot)
    • No Weather apps
    • 3-5 Business apps vs none in Top Paid
  • four free apps in Top Grossing
    • in-app purchases
    • freemium can work
    • talk to Kevin Hoctor who did in-app purchases in Moneywell Express
  • cheap apps get downloads, but higher priced apps pay the bills
    • which would you rather have…?
economics 101:
  • price elasticity of demand
  • how does adjusting the price of a product affect the number that you sell?
  • elastic (e.g. social apps):
    • there’s a common price that people expect
    • if you increase the price beyond that, then demand massively decreases
  • inelastic (e.g. drugs… or photoshop…):
    • people will pay pretty much whatever you ask
    • keep increasing the price and maximise revenue
  • demand curves can move due to marketing campaigns…
  • if you double the price, and you lose less than 50% of your customers, you’ve just made money
    • and fewer users means less support costs
    • also increases perceived value
  • don’t be a commodity — charge what your software is worth

price your app intelligently

  • market segment:
    • lots of basic research
    • category prices
    • start research before starting developing
  • research competitors
    • do you have a big enough differentiator?
  • make a guess
  • then try an experiment
  • example: Kaleidoscope 2
    • developer tool segment: avg price $30.11
    • other apps $70-100
    • app is useful but not crucial
    • lots of alternatives
    • guessed $34.99 intro and $69.99 ongoing
    • got various peak sales that affected average
      • great for recouping costs, but not for calculating ongoing revenue
    • evaluation:
      • elasticity = % change price / % change in quantity
      • with a couple of price changes, you can work out the ratio
      • then apply to price changes to predict quantities and therefore revenue
      • (real world demand curves aren’t linear, so elasticities aren’t actually constant)

Talking to Hardware

Alasdair Allan, Babilim Light Industries @aallan

  • Apple’s External Accessory Framework is missing most of the useful stuff
    • rest is protected by Made for iPhone program
    • which is protected by massive ranks of lawyers
    • because Apple want to protect their platform

crazy stuff

  • jailbreaking
    • average time between a jailbreak release and Apple shutting the hole is about 7 days…
    • can’t release an app to the store
  • MIDI
  • simulate capacitance touch using a piece of foil stuck to the screen
  • PeerTalk: using the USB sync cable
    • uses TCP sockets
    • same protocol as iTunes and Xcode

less crazy stuff

  • wifi is possible, but getting setting up is a pain
    • and there’s lots of support issues for different network situations…
  • acoustic coupling via the headphone jack
    • Square does this for a card reader
    • can even use the audio to provide 7.4mW of power (see Hijack board)
  • Redpark cable
    • dock connector to RS-232
    • comes with an SDK
    • but won’t let you put apps in the store — have to approve the app and the hardware
      • you can approach Redpark and ask them to request approval
      • a lot less expensive than going through MFi program
  • XBee & Zigbee (802.15.4)
    • mesh networking for low data rates
    • dock connector to XBee adapter soon available from redpark
  • bluetooth 4 (low energy)
    • can run for months with bluetooth active powered by a coin cell
    • introduced with the iPhone 4S
    • lots of boards available with Android & iOS SDKs
    • e.g. red bear labs
    • use CoreBluetooth plus board’s SDK
    • easy integration:
      • Alasdair did a live demo in just a few minutes
      • connected to arduino over Bluetooth 4 from iPhone and toggled an LED

TouchDB

Matias Piipari @ms2

https://github.com/couchbase/couchbase-lite-ios

  • CouchDB has been renamed as CouchBase Lite
  • TouchDB is document db with CouchDB-like API
    • but uses SQLite under the hood
  • sync & share with CouchDB (or TouchDB)
  • concurrency controlled like git
    • when you’re saving you have to be up to date first
  • lightweight
    • < 500Kb in app binary
    • 0.1s startup
  • Document <=> Model, with versions
    • can also contain attachments
  • use Views to define queries by property
  • once you’ve configured the replication it will keep going
    • don’t need to worry about network availability
    • do need to think about conflicts
    • do need to think about concurrency with data changes (get notifications on changes)
  • can create push and pull separately and to/from different destinations
    • e.g. combine pull from bundled with pull from remote
  • sync handles https with basic auth or OAuth
  • can combine db from iCloud/Dropbox with TouchDB

Step away from the screen

Nathan Error, Empirical Development @neror

nathan@empiricaldevelopment.com

  • your body is a tool too: improve your coding by improving your body’s effectiveness
    • exercise, diet & sleep…
  • scientometrics
    • measuring rate of change in science
    • rate of output increases by 7% each year
    • output doubles every 10-15 years
    • so whatever we think now will probably change several times over the next 10-15 years
  • maybe start looking at meat more as a side dish rather than a main
  • recent research has linked high intensity aerobic exercise to increased brain performance
  • missing one hour of sleep for a week is equivalent of a blood alcohol level of 0.2%

Subscription pricing

Manton Reece @manton on ADN

manton@manton.org

  • in 1999 working on a Mac app that cost $199
    • actually considered pretty cheap for the time
  • benefits of subscriptions
    • happy customers:
      • unhappy customers can cancel at any time
    • automatic paid upgrades
      • everyone is on the latest version
      • paying for the service
  • to justify subscription, app and service need to be one
  • examples:
    • adobe: switching to creative cloud monthly subscription
    • microsoft: office is now $9.99/month (or $99.99/year)
    • billings pro:
      • free for 1 invoice/month
      • 5 invoices/month = $10
  • focus on the consistent predictable part of the graph rather than the spikes
    • even if you don’t make more sales, the revenue is consistent
  • billing periods
    • payment percentages affect revenues: charging less often means less percentages to payment provider
    • Manton found that 57% of customers preferred yearly billing
  • hosting costs
    • use Amazon reserved instances if you’re committing to a year (saves money)
  • Stripe is leaps and bounds better than paypal…
    • but only available in US and Canada
    • beta coming to the UK this week!
  • Apple in-app purchase types:
    • non-renewing subscriptions: cancel is the default — will probably lose a lot of people
    • auto-renewable subscriptions: better, but more restrictions on review — including privacy policy & description
      • Apple are very cautious about letting non-magazine apps do this

The “Simple And Intuitive” Fallacy

Why we need standards for complex UX, too

Joerg Schweider @cooliopenguin

iPeng

  • iPhones & iPads are not just accessory devices — they are becoming the main device in a lot of cases
  • apps need to be feature complete
  • if you simplify and cut out features then a lot of users will be left out in the cold
  • what makes a more intuitive UI?
    • can’t always find out by getting people to compare UIs
    • they will rate familiar schemes higher

Being Naive

Rob Rhyne @capttaco http://martiancraft.com/

  • “just build something so I can show it to the client”
  • users don’t care about engineering
  • iterate and test
  • at martiancraft, within three weeks of a new project you’re going to see something
    • it won’t be finished, but you can play with it
  • brent simmons: anatomy of a feature
    • the feature is the smallest part
    • it’s all the edge cases and polish that take the time
  • the naive implementation
    • demonstrates the feature
    • most obvious solution
    • takes the least amount of time to develop
  • example: histogram of live video
    • can use Accelerate framework to get histogram data from an image buffer
    • what about drawing the graph?
      • 3rd party charting lib: not obvious; little work; may demo but might not animate
      • OpenGL vertex buffer: not obvious; lots of work; will demo
      • CoreAnimation: obvious (when experienced!); little work; will demo
    • used CAShapeLayer
      • had used previously in Minds of Modern Mathematics
      • 14,000 pixel wide scroll view on an original iPad
      • can set up style once and draw separately
      • path was animatable property
  • http://giveabrief.com
    • codeless prototypes

Working on Sketch

Pieter Omvlee, Bohemian Coding

  • Sketch: vector art app
  • have to persuade users to try us rather than Adobe
  • don’t want a public feature list with voting
    • sets unrealistic expectations
    • there will always be business goals or technical issues that mean that highly requested features remain unfixed at the top
  • listen to your customers, but only to a certain degree
  • started giving away beta versions of app
    • got lots of testers & feedback
    • keep the fans happy
    • they’re very vocal and will do marketing on your behalf
  • don’t leave refactoring until the next big update
    • you’ll want to focus on new visible features to justify the upgrade price
    • customers don’t care about engineering
  • be practical with your time
    • don’t spend time on rewriting git history
    • focus on pricing, attracting the right customers, etc
  • put in crash reporting early
  • videos are excellent promotion & support
    • they take time and lots of takes
  • try and keep in contact with your customers
    • Apple gives you no way of getting in touch with App Store customers
    • but you could ask for details within the app
    • if no newsletter, then Change Logs are your only communication medium
    • “bug fixes” is a waste of an opportunity
  • try and contact bad reviewers

Introducing CoreValues

Scott Morrison (Chief Cook & Bottle Washer), Indev Software @smorr

smorr@indev.ca

  • Indie developer, less Independent, more Individual
  • but not just single person
  • instead individuality & personal
    • personal investment, principles, impact, payoff & risk
  • personal & professional roles are mixed
  • indie company has the heart of the indie developer
  • values are important and define you
    • but sometimes not thought through
    • can lead to inefficient decisions
  • Edward de Bono: if you want an out of the box solution, get out of the box first
    • PO statement — an unconventional (silly) idea used to generate ideas
  • introducing CoreValues: an objective-c framework for describing and defining personal and professional values…
  • interfaces:
    • personal ≠ private
    • professional ≠ public
  • (there was much more in this vein: thought-provoking metaphors, but I didn’t write them down)

Slightly Unsupported — Finder Code Injection

Steve Flack, Bromium UK

  • wanted to add icon badges & contextual menus
    • not based on file type
    • animated
  • used class-dump, x86 disassembler plus lots of trial & error
  • inject code with mach_inject
  • Finder has four methods to swizzle for icon badging
    • one for each view (desktop is fourth)
    • talk gave code specifics for each
  • only two methods to swizzle for contextual menus
    • desktop & grid view share
    • again, talk gave specifics

The Rise and Fall of a Mobile Startup

Emily Toop @fluffyemily

emily@emilytoop.com

  • Tiny Ears 2011-2012
    • app to teach reading to 4-6 year-old children using speech recognition
  • Emily and her partner Ian both got startups accepted to Start-Up Chile
  • had to get speech recognition
    • Google Voice API was best accuracy by far
    • PocketSphinx with OpenEars was only option with no network
    • but all were bad for children
  • can improve recognition with a better model
    • 20 hours to customise a model
    • no existing models for children
    • 20,000 hours to create a new model!
  • Startup Weekend
    • pitch your product
    • then recruit audience to work on it for 48hrs
    • make an MVP
    • really useful
  • talk about your product
    • to everyone
    • until you bore everyone
    • even yourself…
  • used AVAnimator to play movies with alpha channels
  • …but speech recognition model would cost $100,000 and take 18 months
  • then animators didn’t want to continue without speech recognition
  • make your partnerships sound!
  • don’t go alone
    • guides recommend that you have a hacker and a hustler
  • mothballed Tiny Ears
  • joined another startup to learn how startups work
  • getting more involved in education
    • joined Code Club
    • applying to be a reading assistant
  • approached by dreamthinkspeak to help with their “large-scale, site-responsive theatre production inspired by Leonardo Da Vinci, The Book of Revelations and the world of Mechatronics”
    • go see them while they’re still in London (until March 30th at Somerset House)
  • nothing you learn is ever wasted

Monday, 4 March 2013

NSConference 5: Day One

This was my first NSConference and I was impressed. Three days of full-on sessions covering everything from deep technical gotchas, through brutally honest experience reports and even across to basic economics lessons. And the people… I’ve never met so many iOS and Mac developers in one room. Everywhere I turned, there was a developer of an app that I’ve used or know about and admire.

Thank you so much to Scotty and the team. Everything (apart from the wi-fi!) went swimmingly!

iOS performance testing

Bill Dudney @bdudney bdudney@me.com

  • Double check performance even when you think you’re doing it right
  • Watchdog gives you lots of time but user expectation is instantaneous
  • You can use more time on suspend… but don’t go outside watchdog times otherwise app will have to start from scratch
  • Use Time Profiler to check CPU usage on startup
  • VM tracker tells you how much memory is dirty - most crashes come from here
    • Allocations can be low but dirty memory still high
    • e.g. Image allocations
    • Memory gets dirty as soon as you write to it
  • ARC deals with most of issues for you but won’t deal with cycles
    • Can see in leaks
    • Deal with by using weak references
  • Graphics
    • Quartz all happens on CPU
    • OpenGL happens on GPU
    • Separate processor - more power
    • CoreAnimation gives you access without writing raw OpenGL
    • It’s a compositing engine
  • Offscreen rendering can take up lots of time
    • Check offscreen rendering highlight in instruments

searching for speedy searching

Simon Wolf @sgaw or @sw on ADN

  • WWDC 2010 mastering CoreData suggests title contains[dc] $content
  • Can use beginswith to improve speed
  • Even faster use >= 'frog' and < 'froh'
  • But doesn’t work for in-word searching
  • SQLite with full text search FTS (or FTS3, older)
  • Have to build own version of SQLite and include in your app
  • And then can’t use with CoreData
  • Use FMDatabase & FMDatabaseQueue to behave better with threads
  • Use SQLite with FTS to create an index that refers to the Managed Object ID
  • otsNormalizeString string category to remove diacritics (in blog post)
  • FTS search is word based, * is wildcard
  • Can also define “nearness” of terms
  • Need to keep index in sync with CoreData

The ultimate developer toolchain

Richard Morton @richardmorton

  • “if you have a machine and don’t buy it, you will ultimately find you have paid for a machine and don’t have it” — Henry Ford
    • buy a decent developer machine!
  • iOS Support Matrix gives you a good way to find which test devices you need
  • Injection for Xcode: restores “Fix & Continue”
    • uses bundles & method swizzling
  • Xcoverage
    • LLVM provides build coverage
    • instrument program flow & generate test coverage files
  • Mogenerator
  • AppCode by JetBrains
    • would still do bulk of dev in Xcode but boot up AppCode to use refactoring & other unique features
  • Jenkins
  • PaintCode
  • xScope
  • ResourceHelper
    • extra QA for assets

Why making 12 Games in 12 months is a good idea

Matthijs Hollemans @mhollemans

  • lots of game jams around
  • why?
  • experimentation & innovation
  • learning how to finish
    • often there’s a long hard grind to finish
  • learn to limit your scope
    • one single thing
    • take idea and strip it to the core
  • putting constraints on what you’re doing enhances your creativity
  • also get experience in failing to finish games
    • good to find a way to fail faster!

UISS - UIAppearance on Steroids

Robert Wijas @robertwijas

  • UISS available on github & CocoaPods
  • UIAppearance & UIAppearanceContainer lets you set appearance defaults application-wide
  • but need lots of code to do anything…
  • UISS uses JSON syntax, similar to CSS
  • lets you set styles for inner elements
  • and also styles per device type (iPhone/iPad)
  • lets you define variables
  • easily disable bits by prefixing selector with “-“
  • setup:
    • [UISSS configureWithDefaultJSONFile];
    • add uiss.json file
  • debug: UISS status bar
    • tapping status bar shows errors in uiss.json
  • works with live updates in uiss :-)
    • just make uiss.json available via HTTP
    • [UISS configureWithURL:url]
    • let’s you build the app and give it to your designer to adjust, even without Xcode
    • debug option lets you adjust URL
  • generates UIAppearance code for you
    • you’ll want to do that before you create production code
  • can use UIProxy to control your own custom views with UIAppearance
    • also allows you to adjust them with UISS
  • other systems doing same thing:
    • NUI
    • pixate
    • both use traditional CSS - so heavier dependencies

Becoming a product company

Daniel Pasco @dlpasco daniel@blackpixel.com

  • started in 2007 as contracting but aimed from the beginning to be a product company
  • 6 people for 3 years, then doubled in size for 3 years
  • operate as a remote company, HQ in Seattle, but spread over US, with a couple in France
  • have shipped hundreds of apps, but all for other people
    • have a reputation for confidentiality
    • so can’t tell anyone about them…
  • there’s an opportunity cost to do product development
    • in the presence of lucrative contracts, you take a risk and turn away money
  • however, you get stability
    • find that contract work is busy Feb to July
    • occasional spike in November preparing apps for Xmas
  • did client work until they had enough money
    • then did some product work until money ran out
    • then swapped back to contract
    • big gaps between product dev
    • when went back to code, there were lots of changes to make with all the new knowledge…
  • initial product was Bistromath
    • massively over-engineered…
    • developed in a vacuum
  • need to share app with people who know nothing about how the app works
    • tester should not share any of your assumptions
  • life after being featured…
    • intense — but treat it as a bonus
    • people need to be aware of the app outside of the app store
  • painful first product experience made them very gunshy
  • learnings:
    • vet your ideas early on
    • get feedback on betas
    • no excitement? that’s an issue
    • if someone wants to extrapolate — that’s great! but leave those additional features for later
    • have a sustainable dev plan — through to the product release
    • check out marketing
  • changed business model:
    • grew contracting team so could subsidise continuous product team
    • could keep momentum going
  • got the chance to acquire three products from other developers (NetNewsWire, Kaleidoscope, Versions)
    • existing userbase
    • well-known brands
  • products acquired through revenue-share
    • no money up front
    • revenue share decreases as time goes on
  • wanted to share info & blog monthly, but…
    • have competitors: don’t want to reveal feature roadmap
    • no one knows if you miss a deadline: would have announced and missed three times!
    • no one knows if you drop a feature you promised
  • Apple will not let you transfer an app between accounts
    • unless you get the keys to the old account, customers will have to buy the app over again…
    • trying out introductory pricing on upgrades to help people recover their losses
  • iCloud sync issues with NetNewsWire
    • iCloud/Core Data: still unusable…
      • opening the iCloud container can take up to 25 minutes
    • iCloud/Key Value Store: works fine
    • iCloud/Ubiquitous Documents: has issues
  • got creative tensions from people caring so much about their own products
  • changed aim to be frequent, shorter, release cycles
  • got lost with features — endless ticket list
    • @jury drew a line in the sand: ship by this date
    • focus accordingly
    • the plan:
      • 4 weeks for feature complete
      • then 4 weeks for no P3 bugs (fix or defer)
      • then 2 weeks for no P2s
      • then 1 week for no P1 bugs
    • there will always be another release
      • if that isn’t built into your plan — change your plan!
    • it’s ok to ship with bugs, as long as they’re not blockers

Software Architecture: what questions to ask?

Jacob Gorban @apparentsoft

A short list of questions to ask when adding a new feature to your project:

  • good ideas are insidious: they increase scope
    • must definitely be worth adding…
    • here are some questions to think about before adding a new one to your project
  • is it really a good idea?
    • is it good for your business?
    • it it good for your app in the long run
  • is it DRY?
  • is it orthogonal?
    • good to have smaller pieces joined than one big piece
  • is it testable?
  • is there another way?
    • when you see a good move, look for a better one — Emanuel Lasker
  • what is the cost of changing this later?
  • what would the architecture look like if I didn’t have this problem?
    • is this problem framed properly for my app?
    • perhaps we can change the problem…
  • document the rationale
    • not just for later — helps you understand the problem
    • could also discuss with others
  • what are the facts and assumptions?

Download from http://bit.ly/software_architecture_tips_pdf

WebKit UI Inspector Tips and Tricks

Daniel Jalkut, Red Sweater Software @danielpunkass

  • use webkit inspector to fix a page for printing
  • prototype app store previews
  • can set inspector on in your own (Mac) app:
    • just add -WebkitDeveloperExtras YES argument
    • can add same preference on other apps
    • defaults write <bundle-id> WebkitDeveloperExtras -bool YES
    • or globally: defaults write -g WebkitDeveloperExtras -bool YES
  • Dictionary app uses a WebView… so you can inspect it!
  • preference key doesn’t guarantee that the “Inspect Element” menu item will be available
  • Mail.app is a very good robust HTML editor using a WebView but it overrides the contextual menu
  • for any process (even one that has custom contextual menu):
    • attach to target
    • break on [NSView menuForEvent:]
      • lldb: break set -r menuForEvent
    • ctrl-click in the suspected WebView
    • run code: [[[$rdi _webView] inspector] show:0];
      • event target is in $rdi
  • iOS webkit inspector can inspect Safari or any UIWebView in an app that you own

The Invisible Interface — Adding offline speech UI to your app

Halle Winkler @politepix http://politepix.com

  • large vocabulary tasks
    • use server-based speech recognition
    • UITextView, Nuance, AT&T, iSpeech
  • command and control
    • can use offline speech recognition
    • e.g. OpenEars
  • speech API dimension is time
    • make time, rather than just take time
  • small steps through decision tree, means small steps backwards
    • trust & quickly verify
    • switch between small vocabularies
  • watch out for “out of vocabulary”
    • what happens when people walk past talking loudly…?
    • it’s a solved problem in speech recognition, but deciding what to do is a design issue

Thursday, 25 October 2012

MomoLondon: HTML vs Native

A lively and exciting debate (despite the old material!), well-run by Ewan MacLeod, Editor, Mobile Industry Review @ew4n

Panel

Team HTML5

  • Andrew Betts @triblondon
    • HTML5 apps for FT
  • Simon Arora, Biz Dev Mgr, Keynote DeviceAnywhere @devanywhere
    • Initially all about native
    • More and more customers asking for HTML5
    • More platforms with a single codebase
    • No need for appstore or marketplace certification
    • Wider reach to monetise services
  • Jose Valles, Head of Bluevia @josevalles49
    • Been an HTML5 supporter for a long time
    • Launching FirefoxOS device

Team Native

  • Alex Caccia, President, Marmalade @marmaladeapps
    • one of the leading cross-platform build platforms
    • take advantage of ARM instruction set…
    • two of top three games in US app store built using marmalade
    • HTML5 just doesn’t provide enough power - need native for performance
    • HTML5 does not solve fragmentation
  • Chris Book, Bardowl @bookmeister
    • native gives close access to device APIs
    • deal with different network situations
    • HTML5 doesn’t work for audio streaming and caching
  • Nick Barnett, CEO, Mippin @docnickb
    • make app builders for operators and manufacturers
    • provide both HTML5 and native app builders
    • it’s more about the business model and distribution
      • if you want to be in the app store, you have to be native

Last app you paid for?

  • AB: Open House London
    • because their website is appalling and doesn’t work
  • SA: Travel Deluxe
    • native london travel
  • JV: probably a skateboarding app, or tripit or spotify
  • AC: Expense Calculator
  • CB: New Star Soccer
    • 10 games free, then in-app purchases
  • NB: International Rules of Yacht Racing
    • native

All native apps. If you want to buy an app, it has to be in an app store…

What about Facebook?

  • AC: Hardware platform is moving faster than anything else
    • If you come up against an issue, you’re against the browser
    • The only way past is to know the details of the insides of the browser
    • Can’t solve it by logic (terrible for project management!)

FT web app UX

  • EM: FT webapp has to go through local cache expanding step before starting
  • AB: equivalent to installing an app from the store
    • if you say no, it still works; but in a potentially limited way
    • actually a benefit: allows levels of access

Stats from deviceanywhere

  • SA: out of 100 customers, top 25 are looking at HTML5
    • have a lot of enterprise customers
    • looking to increase their reach
  • NB: these customers already have iOS and Android apps?
  • SA: yes, looking to extend reach across devices without decent appstores

HSBC Business Banking

  • EM: it’s an utterly crap HTML5 experience
    • banks say they’d love to do HTML5, but security say no!
  • JV: why then do they have online banking?
    • want to keep customer experience
  • CB: native NatWest app is better than web experience…
    • haven’t been able to update their website in 12 years!
    • loads of apps where you use native app first rather than web site
      • e.g. Hailo, National Rail Enquiries
  • NB: cross-platform HTML5 is a nonsense
    • at Mippin, we build web app builders for each platform separately
  • AB: that’s just ‘cos you’re not doing it very well!
    • FT use same codebase for Android, iPhone, iPad
  • NB: but Windows Phone 7 UX is completely different from iOS
    • customers expect something different
    • so you need to write your UI differently anyway
    • may as well write it natively each time

How do we resolve vested interests? And designing for format?

  • AB: each format and each channel will have differing expectations
    • if you define your constraints narrowly enough, natively will always be better
    • if you have a broad strategy and vision, then web technology will win
    • what about TV? what about kiosks?
    • a single web technology solution will adapt to those situations
    • single code base works with touch, keyboard and gestures too!
    • at a recent hackday, FT Labs connected a Kinect and controlled the app without touching the screen
    • the FT webapp works in the way that the people reading the paper are used to — independent of device expectations
  • AC: want a fine degree of control over what it looks like and how it behaves
    • in gaming environment, you really want to make the app shine
  • CB: isn’t this all about the 30% that Apple want to take out of the subscription?
  • AB: it’s not (exclusively) about the 30% — it’s more about a direct relationship with the customer
    • enables customers to switch devices without losing their subscription
  • CB: but Spotify have native apps and still go cross platform whilst keeping relationship with customers
  • AB: if Apple changed their rules to say that Spotify would have to give a percentage of their revenue, then Spotify would be stuffed
  • NB: if the Daily Mail went the FT route would people get their news elsewhere?

Is it fair to say that HTML5 is destroying usability of mobile platforms?

  • JV: no, it’s building something
  • CB: Google Maps browser version just not as good as previous native version

Hybrids?

  • NB: mippin use unique per platform wrappers
    • PhoneGap works well for iOS, not so well for Android
    • BlackBerry has WebWorks
    • hardcore gaming is a pretty specialist use case
  • CA: use the right tool for the right job
    • SDK supports HTML5 content within an app
    • and then you can switch out and use the native with ease
  • Audience: built a PhoneGap app and was appalled by performance
    • scrolling 50-100 names was just not good enough

Native provides consistent experience?

  • Spotify on some platforms lets you order playlist, Android doesn’t
  • if been written on HTML5, then would have worked fine
  • AB: people put 70% of budget into iOS
    • then 20% into Android
    • then 5% into Windows and Blackberry…
    • not surprising that non-iOS apps are crap

Discovery…

  • JV: 700K apps in Apple appstore, so discovery there is hard too
    • don’t see a difference
  • AB: FT not in a unique position – shared by lots of big brands
    • for small companies, app store is probably a good thing
    • FT have specialist native apps in the store which point users in the direction of the web app

Prisoners of the market owners?

  • NB: usual retail model: retailer takes 30-40% of revenue
    • and benefits can be considerable!
    • if you’re in Brazil in 2 years time with Boot2Gecko devices, then the mindset could be completely different
  • Dan Appelquist: isn’t that the issue — app stores are dragging us back into the old model that the open internet is breaking us out of
  • CB: yes, the dominance is worrying
    • but it’s a business making opportunity for startups
  • CA: native is not closed
    • hardware manufacturers trying to make best user experience

Security in native?

  • CB: difficult to securely store offline data
    • premium audio streaming is not yet possible in HTML5
  • EM: a bank developer said “the security people want a native app for encryption reasons”
  • AB: why does the online banking not just work on the phone?
    • yes, you can have encrypted storage, but do you need it

Best way in for mobile development

  • NB: use an app template toolkit for a size that fits
    • learn to be a mobile developer…
  • what if you just want to see your idea?
  • CA: most dangerous word when you start is “just”…
  • AB: the reason for the standard layouts on web is ads
    • have to build the design to fit the adverts
    • there’s been a boost in design creativity from moving to new formats
    • you can take that newfound focus on user experience and bring it back to the desktop
    • you’d never expect a mobile app to have big gutters down the side
    • unless it’s an iOS 5 app on an iPhone 5…

Notifications

  • NB: issue for HTML5 apps
  • AB: W3C working on notifications as a spec…

New users from India, China & Brazil won’t be in Apple or Google’s ecosystem

  • NB: won’t be a technology decision — more of a distribution

Javascript libraries?

  • NB: 85% of development in HTML5 apps goes into javascript

Great new debugging suites for Android Chrome and iOS Safari

  • Dominic Travers: great time to develop HTML5 apps!

Will we still be arguing in 5 years’ time?

  • AB: native will always be able to innovate faster
    • web will be behind, but standardised
    • FT’s Android app is partly native for performance
    • as soon as the browser catches up, they’ll remove the native part

Announcements

  • W3C coremob.org community group
  • UKTI Competition Final 29th October
  • 7th Anniversary in November