Building Solid Mobile Workflows
•
0 gostou•1,309 visualizações
Mobile applications can be intimidating… especially for iOS and Apple’s walled garden. There’s provisioning profiles, signing certificates, push certificates, entitlements, iTunes Connect & Apple Developer portals, Human Interface Guidelines and a myriad of rules that will get your app rejected or removed if broken. And that’s just the bare minimum to get off the ground with your first app…but who wants to just get off the ground? Instead, build a solid workflow that will greatly decrease friction when developing and maintaining both enterprise and customer facing mobile applications. We’ll take a look at the iOS basic process as well as more advanced process enhancements to really level up your mobile app workflow.
Recomendados
Mais conteúdo relacionado
Último
Último (20)
Destaque
Destaque (20)
Building Solid Mobile Workflows
- 2. Who am I? Why should you care? Mobile Engineer @ URBN inc Builder of native iOS apps. Both customer facing and enterprise Previously at Bluecadet Interactive Design background, writing code for 8 years
- 3. What we’ll discuss & what we won’t Planning & designing a mobile app App Development Workflow Methodology Development Life Cycle Testing Continuous Integration Deployment Not getting into design or code specifics All with an iOS slant
- 4. Planning & Design Experts Required App UX & UI are very different web Not all mobile created equal. iOS & Android require respective experts Understanding platform UX & UI conventions makes your engineers lives easier Lean on your engineers. They are by default platform experts They can help your UX & UI staff create a well crafted, platform appropriate app
- 5. Methodology agile (with a lower case ‘a’) Bare minimum daily(ish) stand ups, sprint planning, demo 2 week sprints Plan to release after each sprint Plan features so they can be completed in a sprint Even if this means breaking up the work into smaller chunks Tools: depends on how hardcore you are Jira, Trello, Basecamp (from hardcore to laid back)
- 6. Sample Schedule Week 1 Tue: Sprint Planning Wed: Sprint starts Week 2 Thur: Sprint Grooming Week 3 Mon: Sprint Demo. Release candidate distributed to larger testing group Tue: next Sprint Planning Rinse & Repeat Submit to App Store Always hold for developer release
- 7. Development Life Cycle (Version Control) Source/Version Control is a must! 3 base branches (master, beta, dev) Pull requests for major work (multiple files changed) Pull requests should be reviewed (when possible) Commit and push often. Nothing is too little to commit Make commits as small and inclusive as possible. Avoid commits with multiple functionality changes Commit messages should be as concise and descriptive as possible
- 8. Development Life Cycle (Sample) Branch off dev. Name branch after feature ticket Feature complete, pull request into dev Reviewing dev accepts, merges into dev Sprint complete. Merge into beta. Release candidate built from beta Release candidate has a bug Branch off beta, fix the bug, merge the branch into beta and dev Release candidate approved. Merge into master Prep for App Store submission on master Submit to App Store from master
- 9. Testing & Quality Control (Robots) 1st Line of Defense: Unit Tests Great for model level code (data) & data modification code 2nd Line of Defense: Automated UI Testing Test user interactions and typical user flows Robots are great at testing happy path Not so good at edge cases If you're spending more than 1/3 of your time writing test cases, you're doing it wrong.
- 10. Testing & Quality Control (Humans) Last Line of Defense: Humans Never release code without actual humans testing it Someone other than yourself What to test? New features/code (duh) Regressions (everything) Just because because you think new code doesn’t effect some old code doesn’t mean you’re right Never release with out full regression testing
- 11. Testing & Quality Control (Strategy) Testing starts with the developer. Be a good citizen. Dev releases often so features can be tested continuously, not just at the end of the sprint. Writing testing scripts so you don’t miss anything Ensure complete device and OS coverage Every device the app will run on (iPhone 4s - 5s) Every major AND minor OS release (6.0, 6.1, 7.0)
- 12. Continuous Integration (CI) Constant releases based on Source Control commits and a tool like Jenkins Your CI tool should: Pull newest code Run unit tests Build latest code Run Automated UI Tests Create a new build & submit to a software distribution service (like TestFlight) Compile release notes based on commit messages Notify developers of pass/fail
- 13. App Deployment Have a checklist Release builds off Master Before submission, test the upgrade process from current production app to new version Ensure all services are receiving and reporting the new version Final verification that all features and updates are in fact there Verify push notifications work correctly Submit to the App Store & “Hold for Developer Release”
- 14. Post Deployment Monitor production crash reports Compare against previous versions Look for new and increasing crashes Take reviews with a grain of salt (haters gonna hate) Use crashes, reviews, and other feedback mechanism to plan future sprints Dogfood your app!
- 15. Tools Source Control (Git) Dev & Beta distribution (TestFlight) Ticket tracking (Jira) Crash reporting (Crittercism) Analytics (Appboy/Localytics) Communication (Appboy)
- 16. Extras Get an Enterprise account (unlimited devices, no UDID wrangling) Apps are nothing without strong services Don’t try to roll your own Push Service Don’t try to support too many OS releases Respond to user feedback Get to WWDC and get your app/designs reviewed by an Apple UX Specialist (invaluable) Download and use every app you can find Gestures are sexy, but don’t rely on them Read the HIG (Human Interface Guidelines)