How to lose at poker (Mike Lee, @bmf)
- emotion/intuition vs. reason in cards - those who ultimately win are not those who follow their intuition and emotions, but those who resist the temptation to do that; e.g. an "inside straight" (5 6 x 8 9) is twice harder to complete than other straights (x 5 6 7 8 x) even though it feels just as likely, so it's reckless to try to get one
- chance of failure is never 0%
- it's not about winning all the time, it's about managing your wins in a sea of losses, and using your losses to your advantage
Core Data Sync with Ensembles (Drew McCormack, @drewmccormack)
- backend-agnostic Core Data sync library
- uses iCloud/Dropbox as a sync mechanism, sends CRUD operations as files and reassembles the DB on the other side
- easy virtual filesystems
- represent anything (eg. app's internal database) as files and folders
- implement a delegate with a few required methods
- integration with Spotlight
Treasure Map(-Kit) (Alexander Repty, @arepty)
- MapKit seems very important for Apple, they've spent a lot of time and money to become independent from Google Maps
- it went through a lot of changes a few times
-
use customized annotations (markers) and provide relevant information
- what kind of information helps the user in this case? (e.g. item price)
- can the user quickly identify what it is?
- don't make them tap many times and follow many steps to get the info they want
- see Apple's docs
- use object-specific images if available
- if you have many types of markers, make them easy to distinguish
- make sure anchor point is set properly
-
use customized popup (callout) views if it makes sense
- show most relevant info (e.g. Apple's friends app - zooms the avatar, shows ways to contact the person at the top)
- use standard callout views if possible, but use custom views or custom selection behavior if necessary
-
if you have many markers, implement clustering
- also provide information in clusters (e.g. through color or saturation)
- get designer help
- use animations when merging/separating clusters
- use an off screen MapKit view with separate markers and cluster them on the on-screen one
- "Visualizing information geographically with MapKit" - WWDC 2011 video with an example (bad performance though)
- reimplemented as an example here: https://github.com/alexrepty/MapKitDemo
- ARClusteredMapView - MKMapView control with clustering
Weirding Way (Jonathan D. Rhyne, @jdrhyne)
Tips for business negotiations:
- start in a friendly way
- be thankful when they do something good for you
- make them feel important
- don't criticise your customer
- try to see things from their point of view
- avoid arguments with the client
- make them feel like the idea is theirs
- difference in animation behavior between views and layers: layers auto-animate any property changes, views don't (views are backed by layers, but they block default layer behavior, unless it's done inside an explicit animation block)
Life Outside the Mac App Store (Paul Kim, @mr_noodle)
When you distribute your app through the App Store:
- you lose direct access to your customers
- you might have to lose some functionality because of the sandbox or other App Store rules
- you have less control over the release schedule
When you stay outside MAS:
- you can't reach as large user base as through the App Store, some users only use MAS because of convenience or fear about security
- Apple might be dropping support for non-MAS apps in future? (but some indie devs reported they explicitly told them unofficially that they respect them and that they won't do that)
- but there are still a lot of people who will buy your app anyway; people who sell apps both ways report that they often get more users outside the App Store than inside it
- you're in good company, e.g.: Alfred, Postbox, Path Finder, TextExpander, etc.
Tips:
- services that handle everything: FastSpring, Digital River, Shopify (~9% commision)
- Potion Store - self-hosted (3-5%)
- Sparkle for updates
- Dropbox for syncing
- marketing - you should be doing this yourself anyway
- word of mouth is your most powerful marketing tool - turn your users into fans (provide good support, focus on implementing features for existing users to make them happy); it takes time, be patient
- use the fact that you're not restricted by the sandbox as your competitive advantage:
- use APIs and features that other apps can't use
- integrate more with other apps in the system
- release often since you don't need to wait for review
- a middle layer between
NSURLConection/NSURLSessionand lower level socket code - intercept any subset of network requests from the app and preprocess them or completely handle them yourself
20 Years of Indie Development (James Thomson, @jamesthomson)
- get your code ready for day one of whatever new thing Apple is releasing, it may turn out to be worth it if you get featured somewhere by them
KVO Considered Awesome (Amy Worrall, Black Pixel, @amyruthworrall)
- MVC = Massive View Controller :P
- old pattern: View observes Model, Controller only handles user input
- current approach: Controller became something between the Model and the View
- KVO lets you go back to that original approach
BOOL accessInstanceVariablesDirectly- controls if KVC can access ivars (yes by default)setNilValueForKey:- what to do if you callsetValue:forKey:with a primitive type and passnil- validation - only called automatically when saving a Core Data context, or when using bindings
- instead of observing
fieldin the model directly, observemodel.fieldin the controller, then you don't need to update the binding when the model object is replaced observeValueForKeyPath:ofObject:change:context:- runsuperif it's not a change you're monitoring, but only if the superclass actually implements this method- MAKVONotificationCenter - better API for KVO
- trust your instinct if you see any red flags
- stop working if payments are late
- never send an email if you're angry (or insult someone who owes you money)
- "The law is an ass" - avoid courts if at all possible. If you need to go to court, you've already lost. It matters more who has more money and better lawyers, than who is right. Write off debt rather than go to court.
Red Meat and Gin (Rich Siegel, Bare Bones Software, @siegel)
How to stay alive as a company for a long time?
- solve interesting problems with long term solutions
- build things to last: have good engineering discipline (e.g. no warnings in the build)
- feature freeze periods before releases
- ship when it's ready, not before - only when you've implemented and fixed what you wanted
- create processes to make your life easier
- have documentation to reduce noise from bug reports - if users report something too often, it means something is wrong with your UI and/or documentation
- be flexible - don't get locked in to five-year plans (but have some idea where you're going)
- idea: configure breakpoints to emit sounds and continue when they hit, it makes it easier to debug various problems e.g. related to performance
- no official API - it sort of works by auto-loading plugins from /Library/Mail/, but Apple likes to break it quite often
- implemented mostly by swizzling methods to override behavior
- constant upgrades, because Mail rejects plugins that aren't explicitly compatible with new version
- using class dumps to analyze behavior and the API
- restricted by Mail's sandbox and its selected entitlements
- can't use open source libraries, because all plugins run in the same process, so if they use other versions of the library there will be conflicts... you need to either reimplement them or prefix everything
- it's hard, but there are many millions of Mail users, and many of them will be willing to pay for something that extends or fixes it
While Nobody is Looking (David Smith, @_DavidSmith)
- unexpected delight: surprise the user by doing something they will love but didn't expect
- requires understanding of the user's needs
- understand the user's context and respond to it: where, how and why they interact with the app; it requires some detective work and getting out of your routine
- explicit context: where the user is in the app and what they have just done
- implicit context: extrapolate from available data; e.g. behave differently on different devices, in flight mode, in low power situation, on the move, in low light condition (dark mode)
- make sure you don't confuse the user and that you make it obvious what's happening and how to undo the change
- problem: adding a lot of fields to the database that duplicate data e.g. for search/indexing purposes
- two types of data mixed in the tables: actual data and UI data (derived from actual data, can be recreated)
- causes problems with sync, backup, migrations
- solution: keep two databases separately, one with the real data and one with derived data that can be rebuilt at any time
- potentially increases complexity, so only makes sense when the derived data becomes a problem
Not Invented Here (Marcus S. Zarra, @mzarra)
- all code sucks eventually
- manage your risk when using third party libraries: they can always break, be broken by Apple's updates, stop being updated and get stale... at least understand how they work and how the underlying framework works
- KVO: all notifications are handled through a single method, problems with strings
- notifications: too loosely coupled, it's hard to say who speaks to whom
- delegates: better because you can do compile time checks, the relation is more explicit
- PSTDelegateProxy - makes it easier to call delegates
- HTDelegateProxy - supports multiple delegates
Land or Slam (Luc Vandal, @lucvandal)
- scratch your own itch: if you want something to exist but no one wants to do it, do it yourself
- use unique opportunities that only exist for a short period of time
- focus on a smaller amount of projects to get better results
- you have to start with UX and then add the technology, you can't start with technology and then figure out how to sell it
- make it seem like it wasn't a lot of work
- be passionate about what you're doing and have fun doing it
- CTO stands for "Career Technically Over"
- tips from Bil the CTO:
- don't fight the frameworks - before you implement something, first check if Apple doesn't already provide it in the SDK
- when you find bugs in Xcode or the SDK, file radars and attach sample projects that reproduce the issue
- have good, skilled QA people on the team and treat them as well as developers and designers
- your job has an expiration date - we engineers always get bored after some time (even at Apple)
- to build a company, you need three people/roles: an engineer, a designer and a dictator
- you need someone who will build this
- there are actually companies who try to build something without an engineer, but you never hear about them because they never ship
- we want to build the perfect system (like that guy in Tron), to reduce chaos and inefficiency
- we're willing to take time to go deep to understand something
- we prepare for the unexpected by being paranoid
- we believe there are always rules that will let us predict what's going to happen
- we can go to insane lengths for small efficiency improvements
- we love signal, hate noise
- we just have an urge to build something and we consider none of this as "work"
- ... but your product will be used by humans, so you need a designer to translate the vision for humans and make the software usable for them
- they understand what most users want, can describe it and prioritize based on this
- they can surprise and delight users
- with a developer and a designer, there is a wonderful battle between art and science, so you also need a dictator, someone to make a decision
- a good dictator allows for consistency that is usually killed by politics and design by commitee
- they have the power to say no - to kill projects, to fire people
- great dictators are like forces of nature
- figure out which one you are - you are probably horrifically bad at some of these
Software Design & Eclecticism (Mattt Thompson, @mattt)
- FormatterKit - a set of classes for formatting numbers, addresses etc. in a localized way
- CFStringTransform - Apple's API for transforming strings in various ways
Post-Apocalyptic Technical Ethics (Halle Winkler, @Politepix)
- we've gone right from the utopian phase to the dystopian phase
- most of us work for some companies that collect user data, and it's an opportunity for us to promote good ethics
- don't require moral perfection, everyone should take part in this discussion regardless of their opinion
- Eric Schmidt: "If you have something that you don’t want anyone to know, maybe you shouldn’t be doing it in the first place."
- user isn't really informed when they consent to gathering their data, they don't really realize what's going to happen with this data and what the relation is, so you can't assume they've agreed to that
- speak your values when someone proposes something you think is bad (present it in a mild, neutral way, they might have not realized it's bad; use persuasion instead of arguing)
- be careful about collecting data you don't need
- erase data you don't need anymore (including backups etc.)
- strong encryption for everything - as a collective immunity
- use a warrant canary
- off topic: it's not like you think, that no one here works in consulting and everyone lives off the App Store ;)
- bezier path: control points p0..pn, degree n
- used in vector graphics, animations
- spline/path built from curves
CGPath,NSBezierPath,UIBezierPath- blurriness: draw at position 0.5 to avoid it (see "Are your rectangles blurry")
containsPoint:- hit testing
Surviving the Game… Dev – Making a Career out of “Bad” Decisions (Jeff LaMarche, @jeff_lamarche)
- sometimes the greatest opportunities come from decisions that other people regard as bad (like jumping onto the new thing that everyone thinks won't work)
- if it looks like a bad idea, it might actually be a good idea, you just need to find a way to turn it into one
- get free advertising by sharing your development process
Building App Communities (Steve "Scotty" Scott, @macdevnet)
- if you build a community of your users, such that people feel like they belong there, they will stay with you even if you make mistakes, even if they don't have a good reason
- gather people in one place (not necessarily a physical one) for a common purpose
- find a way to make them want to be there, they need to be able to get something from being there
- facilitate communication, but don't try to control it
- make sure that the people that don't currently gain anything from being in your community can benefit from being there
Being Apple (Lex Friedman, @lexfri)
How to be appleish?
- be patient - don't release what is not ready
- be ambitious and adventurous
- always be selling - try to turn even haters and disappointed users and people you can't help into actual happy users
- don't just say no, but explain
- use release notes and support emails to get users interested and involved
- Apple and Facebook know that people hate changes, but they take risks anyway, because it's worth it in the long run
- make your customers feel heard
- you don't have to fix everything right away, but communicate with the users