Scaling an app means many things. They can be human things, like "how do I stop someone from overwriting my changes to the project.pbxproj, storyboard, or xib?" Or development things, like "how do I manage dependencies?” and “why do I always have to do a 3-way merge?” Or even peripheral things like “what happens to our servers if we get featured?” and “what happens to the app when the servers go down?” This session will cover common scaling problems, and solutions to overcome them.

1. Can’t Handle My Scale
@MicheleTitolo

4. Apps

5. CODE

6. Dozens of sub projects?

7. You have a
dependency problem

8. this doesn’t mean everything
has to be shared

9. Create internal libraries with
care

10. version, version, version

11. version

12. 3rd party code

13. Be picky

16. Any code you add,
you will need to maintain

17. Styleguide

19. Establish your conventions

20. Enforce your conventions

21. …
Profit!

22. User Experience

23. Users expect apps from the
same companies to be similar

26. Developers

28. Our tools aren’t the best

29. Falling back to patching base and 3-way merge...
Auto-merging MyApp.xcodeproj/project.pbxproj
CONFLICT (content): Merge conflict in
MyApp.xcodeproj/project.pbxproj
Failed to merge in the changes.
Patch failed at 0037 Launch screen images update
The copy of the patch that failed is found in:
/tmp/git/.git/rebase-apply/patch

31. via textfromxcode.com

32. Communication

34. Identify collision points

35. Architecture discussions

36. Compartmentalize

37. Be aware of
(unknown) dependencies

38. Management

40. Help or hinderance?

41. Our work needs to be
structured

42. Managers should help

44. If they won’t help, they will
hinder

45. Users

46. Going viral is great

47. …but can you handle it?

48. 500
375
250
125
0
April May June July Untitled 1 Untitled 2 Untitled 3
Time

49. 400
300
200
100
0
April May June July Untitled 1 Untitled 2 Untitled 3
Time

50. Crashes

51. The larger your userbase, the
more crashes will happen

52. Software isn’t perfect

53. Goal: limit crashes

54. Goal: recover from non-fatal
errors

55. Goal: TRACK!

56. Servers

60. If your servers crash…

61. …how is that different than
offline mode?

62. If possible, be ready for heavy
traffic

63. Be ready for traffic at different
times

64. via Flurry

65. Have a plan B

66. Services

67. Many services charge per user

69. Make sure you can afford a
service

70. Services also tend to have caps

71. 400
300
200
100
0
April May June July Untitled 1 Untitled 2 Untitled 3
Time

72. Make sure they won’t
disappear (or start lying)

73. Customer Support

74. Expect ~10% of your users to
contact you

76. More, if you have in-app
feedback

77. Users like knowing they are
heard

78. Someone needs to verify their
reported bugs

80. The more obvious the bug, the
more you will hear about it

83. Scale isn’t all bad

84. Scale means you’re
succeeding

85. Scale means you’re
having an impact

86. These are ultimately
good problems to have

87. Thanks
@MicheleTitolo