https://www.coursera.org/articles/ios-app-developer

Swift Basics (How this will be achieved using this course: 

• https://www.hackingwithswift.com/100)

• https://books.apple.com/book/ap-computer-science-principles-with-swift/id1456795905?l=en

• https://books.apple.com/us/book/intro-to-app-development-with-swift/id1118575552

• https://books.apple.com/us/book/intro-to-app-development-with-swift-teacher-guide/id1118577558 d. https://books.apple.com/us/book/ap-computer-science-principles-with-swift/id1456795905

Frameworks

• https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WhatAreFrameworks.html#//apple_ref/doc/uid/20002303-BBCEIJFI

Apple Documentation

• • Swift https://developer.apple.com/swift/resources/

  • Design Guidelines https://developer.apple.com/design/human-interface-guidelines/

  • Accessibility https://developer.apple.com/accessibility/

•  Tutorials

  • https://www.raywenderlich.com/28797163-your-first-ios-swiftui-app-an-app-from-scratch

  • 100 Days of Swift https://www.hackingwithswift.com/100

  • 100 Days of Swift UI https://www.hackingwithswift.com/100/swiftui

  • Swift Knowledge Base https://www.hackingwithswift.com/example-code

  • Swift unit testing tutorial https://www.raywenderlich.com/21020457-ios-unit-testing-and-ui-testing-tutorial

  • UI testing

    • https://www.hackingwithswift.com/articles/83/how-to-test-your-user-interface-using-xcode

    • https://www.hackingwithswift.com/articles/148/xcode-ui-testing-cheat-sheet

  • Objective C to Swift https://www.hackingwithswift.com/articles/114/objective-c-to-swift-conversion-cheat-sheet

Free courses

https://www.coursera.org/professional-certificates/meta-ios-developer

Mobile app architecture refers to the way in which a mobile app is designed and structured. This includes the different components and modules that make up the app, as well as the relationships and interactions between those components and modules.

• A good mobile app architecture is important because it helps to ensure that the app is scalable, maintainable, and easy to develop and test. It also helps to ensure that the app is performant and provides a good user experience.

• There are many different approaches to mobile app architecture, and the best approach will depend on the specific requirements and constraints of the app. Some common architectural patterns for mobile apps include the following:

• Client-server architecture: In this architecture, the mobile app acts as a client that sends requests to a server over the network. The server processes the requests and sends back responses, which the mobile app then uses to update its user interface.

• Layered architecture: In this architecture, the mobile app is divided into different layers, with each layer responsible for a specific set of functionality. For example, the presentation layer might be responsible for the user interface, while the data access layer might be responsible for accessing data from a database.

• Model-view-controller (MVC) architecture: In this architecture, the mobile app is divided into three main components: the model, which represents the data and business logic of the app; the view, which represents the user interface of the app; and the controller, which coordinates the interaction between the model and the view.

Overall, the best approach to mobile app architecture will depend on the specific requirements and constraints of the app, as well as the preferences of the development team.

Write a short summary of what problem the article will solve. Use step-by-step instructions to help people solve the issue. 

UX Design for Mobile Developers

• https://www.udacity.com/course/ux-design-for-mobile-developers--ud849

A mobile app CMS (content management system) is a software platform that is used to manage and publish content for mobile apps. It provides a user-friendly interface that allows non-technical users to create, edit, and publish content for mobile apps without needing to have any coding knowledge.

1. A mobile app CMS typically includes features such as a content editor, a media library for managing images and other media assets, and tools for managing users and permissions. It may also include integrations with other systems, such as a CRM or e-commerce platform, to allow for easy management of customer data and transactions.

2. Mobile app CMS platforms can be a useful tool for organizations that need to publish a lot of content for their mobile apps, such as news organizations, e-commerce companies, and educational institutions. By using a mobile app CMS, these organizations can save time and resources and make it easier for their content teams to publish and update content for their mobile apps.

https://medium.com/@dfs.techblog/server-driven-ui-concept-db07d7946e94

Without API you cannot build a mobile app. The majority of the application require data from the server.

1. AWS, Azure, GCP

2. Firebase, AWS Amplify

Mobile app monitoring is the process of tracking and analyzing various metrics and other data related to a mobile app, in order to identify problems, optimize performance, and improve the user experience.

To perform mobile app monitoring, you will need to use a combination of tools and techniques, including the following:

App analytics: Use app analytics tools to track key metrics such as user acquisition, engagement, retention, and revenue. These tools can help you understand how users are interacting with your app and identify areas for improvement.

Crash reporting: Use crash reporting tools to identify and diagnose any problems or bugs that are causing the app to crash or malfunction. This will help you fix issues quickly and improve the app's stability.

Performance monitoring: Use performance monitoring tools to track the app's performance, including its memory usage, battery consumption, and network usage. This will help you identify any bottlenecks or inefficiencies that are impacting the app's performance.

User feedback: Collect and analyze user feedback through surveys, reviews, or other feedback mechanisms. This will help you understand how users are feeling about the app, and identify any areas where they are having problems or where they would like to see improvements.

Overall, mobile app monitoring is an ongoing process that involves using a variety of tools and techniques to track and analyze the performance and behavior of your app. By regularly monitoring your app, you can identify and fix problems, optimize its performance, and improve the user experience.

1. https://www.dynatrace.com/news/blog/what-is-mobile-app-monitoring/

2. https://www.forbes.com/sites/frederickdaso/2022/05/17/instabug-raises-46m-to-create-the-mobile-observability-and-performance-monitoring-platform/?sh=142e3a407e84

3. 
   

Automate, Automate and Automate. Anything you are going more than 2 times, Automate it. No Discussions.

1. Continuous Integration and Delivery

https://www.mobile.dev/

https://www.coursera.org/learn/uva-darden-continous-delivery-devops

2. Code Documentation

3. Static code analyses

4. Unit Testing

5. UI Automation

6. App Publishing

7. Architecture

   1. https://www.archimatetool.com/

1. 1. A mock server for a mobile app is a simulated version of a server that is used for testing and development purposes. It is typically used to simulate the behavior of a real server without the need for an actual server to be up and running.

   2. The mock server can be used to test various aspects of the mobile app, such as its ability to handle different types of network connections and different types of data input. It can also be used to simulate different server responses, such as error messages or delays, to test how the mobile app handles these scenarios.

   3. There are various tools and frameworks available to create mock servers for mobile apps, such as WireMock, Nock, and json-server. These tools allow developers to easily create and configure a mock server, and can be integrated into the app development workflow.

   4. It can be beneficial in testing the mobile app's functionality and performance in a controlled environment, where developers can easily simulate different scenarios and test the app's behavior without having to rely on an actual server.

1. 1. https://abhivaikar.github.io/howtheytest/#/

   2. https://github.com/abhivaikar/howtheytest/

There are many different key metrics that can be used to measure the success and performance of a mobile app. Some common examples include:

1. Downloads: The number of times the app has been downloaded from an app store or other online marketplace.

2. User acquisition: The number of users who have downloaded and installed the app, as well as the rate at which new users are acquired over time.

3. User engagement: The level of engagement and interaction that users have with the app, including how often they use it, how long they spend using it, and what features they use the most.

4. User retention: The percentage of users who continue to use the app over time, and the rate at which users are lost or churn.

5. User satisfaction: The level of satisfaction that users have with the app, as measured through surveys, reviews, or other feedback mechanisms.

6. Revenue: The amount of money that the app generates through in-app purchases, subscriptions, or other monetization strategies.

7. Cost per acquisition: The cost of acquiring a new user for the app, including marketing and other expenses.

Overall, these are just a few examples of the many key metrics that can be used to measure the success and performance of a mobile app. The specific metrics that are most important will depend on the goals and objectives of the app and its business model.

Measure Metrics (AARRR)

1. ACQUISITION - Users downloading the app from play and app stores

2. ACTIVATION - users enjoying the app - First impression

3. RETENTION - Users coming back and using the app multiple times

4. REFERRAL - Users love the app and refer others to download it

5. REVENUE - Users completing actions on the app that you see monetizing or adding value to the enterprise

1. Deployment frequency

2. Lead time for changes

3. Time to restore service

4. Change failure rate

To build a mobile library, SDK, or framework, you will need to follow a series of steps that will involve both technical and non-technical tasks. Here is a general overview of the process you might follow:

1. Identify the purpose and goals of your mobile library, SDK, or framework. This will help you determine the key features and functionality that you want to include, as well as the target audience for your project.

2. Research existing mobile libraries, SDKs, and frameworks to identify any similar projects that are already available, and determine how your project will be different or unique.

3. Develop a detailed plan or blueprint for your mobile library, SDK, or framework. This should include information about the user interface, the core functionality, and the technical implementation details.

4. Begin coding your mobile library, SDK, or framework. This will involve creating the necessary classes, functions, and other code elements that will make up your project.

5. Test your mobile library, SDK, or framework to ensure that it is working correctly and meeting all of your project's goals and requirements. This will involve both manual testing and automated testing.

6. Document your mobile library, SDK, or framework, including instructions on how to use it, how to integrate it with other projects, and any known limitations or issues.

7. Release your mobile library, SDK, or framework to the public, either through an online repository or as a standalone package. This will make it available for other developers to use and build upon.

8. Overall, building a mobile library, SDK, or framework is a complex process that will require a combination of technical skills, project management skills, and attention to detail. But with careful planning and execution, you can create a valuable tool that will be useful to other mobile app developers.

Here are a few tips to help you decide if you should make something a library/SDK/framework or not.

1. Close more sales

The biggest reason to create a mobile SDK is to help sales and business development staffs close key deals faster. The SDK does this by helping move the process of integrating services along more quickly.

2. Speed up deployment

Time is a critical cost factor because the integration services are performed by mobile engineers with highly valued skill sets. Having an SDK can help them simplify their projects and enable the integration of APIs that require complex use cases that are complemented by standard on-client processing for mobile devices. A SDK greatly simplifies this integration effort.

3. Increase security

Security may be a critical issue. In the case of large ad networks, SDKs are often required in order to reduce programmatic fraud. SDKs can be used to encrypt portions of the user interface (UI) to secure data quality. Mobile payments processing requires PCI compliance and some platforms may have specific requirements for storing passwords, etc. A SDK can help provide that needed security.

4. Reduce bad code & ensure best development practices

Developers are rarely perfect. Even the best can make mistakes. Errors in how data is passed to back end services can cause critical issues and delays that impact the entire business. Inefficient code by a single developer can take down services for across the enterprise. The SDK can go a long way to reducing bad or inefficient code and its impact on critical systems. The right SDK can further insure the right business rules and practices are in place across their entire publisher network.

5. Control over your brand

Control over your brand with the UI of the publisher’s app may be critical to your business. Developers aren't designers; an SDK will allow you to lock down critical portions of the interface while retaining analytics needed to see how the users interact with your service within the publisher’s application.

6. Do you have another place to use the functionality?

Do you have another place to use the functionality. Whether we’re talking about custom widgets in your UI or utilities to help you accomplish certain tasks, it’s important to make sure you have another place to use the functionality before you spend the extra time extracting the code into a library.

If you don’t have another place to use the functionality, don’t worry, just write it for the purpose at hand and you can always extract it later if something else comes up. This also has the added benefit of letting you use it in practice to learn the best way to consume your code.

7. Is there something else out there?

Is there some other open source library that accomplishes what you need? Do your research to make sure you aren’t just reinventing a wheel someone else has created. If you come across a quality library that solves your problem, then you’ve just saved yourself all of the time it would have taken you to write it in the first place.

If you find some open source code that comes close to solving your problem but isn’t quite there, get in touch with the maintainers to see how you can contribute. Perhaps your missing feature is something that they’ve been looking for but haven’t had the time to implement. In that case, the open source community would welcome your contribution.

8. Is the feature truly custom?

Sometimes the feature you’re working on seems like it could be used in many other places, but each implementation is quite different from the last. This type of custom implementation is how us consultancies make it, and shouldn’t be overlooked.

If you were to use a library and would have to customize most parts of the implementation or alter the library code to make it work in different scenarios, then it probably doesn’t make much sense to spend the time making a library out of it.

SDK Best Practices:

1. Easy to use and integrate

2. Performance

3. Consistent Architecture across all Coca-cola SDK 4. Minimum use of resources

5. Maximum compatible

6. Provides own UI

The entire SDK consists of:

1. The API libraries and their reference documentation

2. Concepts/Developers Guide

3. Build/Deploy Guide. Describes how to build an app that uses the API, how to test it, how to deploy it to devices in both test and production. Training: Tutorials/Online Lessons

4. Sample code

5. Registration and API Key web site.

6. Development and Testing tools. This part differentiates an SDK from an API. Developers need tools for analyzing and testing every aspect of their software, including debuggers, performance testers, unit test frameworks, test harnesses, build environments, and (for software that runs on particular devices) test devices or test units.

Mobile SDK - API/Backend Expectations

Pre-requisite

1) Need a API specification which is well defined.

• Endpoint(DEV/QA/PROD) Header parameters

• Input

• Output

• Error messages

• Sample input and output for testing the Api’s

2) What mechanism will be used for securing API’s? So that someone cannot create bots and overload the api’s.

3) API endpoint follows the rest style if possible. Specially the versioning. It is very important so that Mobile Clients keep working even there is new

release of API available.

4) Naming specification should be same across the all interfaces which are grouped together in SDK. It doesn’t matter which naming convention API team chooses, just need to make sure it is consistent.

5) Unit test – This is optional but hope API team does.

6) Any change in specification contract, should be notified to SDK team and others concerned teams.

7) Define who is responsible for the Test data since Mobile app team needed and it is better to be documented.

8) Make Postman available for the API’s so that the whole team can use the same. This will help save time in troubleshooting.

9) Document the timeline when first version of the specification will be available so that SDK team can start with the implementation.

10) Notify the team when endpoint goes down for maintenance etc.

11) All team members should have kick off in the beginning of the work to have common understanding of the api’s.

• API

• SDK

• Mobile App Client QA if there any.

12) Define working. A working API would be just developed or working with various output like success and failure. This would ensure we can correctly design the API to be exposed from the SDK

Expectations of the current style of work

1. Rework because of no spec finalization

2. Changes in API after completion because of no involvement during design phase

3. Unit test cannot be written if the design is iterative, it will be done only post finalization

4. Unstable possibly because of no test data to test out the SDK

5. Time to ship for SDK is different from API because of various steps involved

6. Not finalized SDK documentation till the time spec are finalized

7. If SDK team is not involved during design discussion, we would not be accountable for design queries at the later stage.

SDK Development Process

How much SDK team takes to deliver one line of code change when there is a change in Client interface?

Time : Approx takes 8 hours.

How much SDK team takes to deliver when there is a change such as input in Backend API?

Time: 8 hours per platform.

How much SDK team takes to deliver when there is a new Backend API?

Time: 8 hours per platform when design discussion required. If SDK team already have complete understanding of the new api, then it will take 6 hours per platform.

What is in SDK packaging/Delivery?

1. Binaries

2. Dependencies

3. SDK Client interface Documentation

4. How to SDK Integration Guides (Read Me) 5. Sample Application Binary

6. Sample Application source code

7. Unit Test Cases

Steps for Building Mobile SDK

As we are getting into building new SDK's and asking third party developers/agencies to provide us the SDK for Android and iOS. It will be good to provide set of requirements and set the expectations from the beginning.

Requirement gathering

Why we need SDK? What particular problem it solves? How it will benefit the clients? Conduct interviews with business owner and Client app developers.

Review 1. Do we need a Mobile SDK? checklist.

Analysis

Analyse requirements to ensure extensibility and maintainability.

Design

If you are writing new SDK from scratch please discuss with Coca-Cola mobile team for the Client Interface which will be consumed by Mobile apps.

Develop/Implementation Requirements

1. Manager

2. Client Interface

3. Versioning

4. Ability to turn on/off logging

5. Code documentation

6. SDK Documentation should be in format of Java doc or apple style. So that you can run doxygen etc.

7. Ability to change API Endpoint without updating the SDK. There should be method for configuring Endpoint from application.

8. Various OS architecture support

1) Android : Should support all device architectures. 2) iOS:

a. We need FAT/Universal framework(simulator/all device architectures) b. Swift Packages

i. Swift Packages

ii. Creating a Standalone Swift Package

iii. Binary Frameworks as Swift Packages

9. Designed for consuming less runtime memory

10. Internal classes should be marked appropriately.

Unit Test and Code Coverage(75% above)

1. Test cases

2. SDK Interfaces

Delivery

1. Binaries

2. SDK dependencies

3. SDK Documentation

4. How to integrate SDK guide step by step?

5. Sample app binary and source code

6. Packaging options for Android AAR vs JAR

7. Proguard and Obfuscation, provide a list of proguard if it is enabled on sample app.

SDK Release plans/Roadmap

1. Internal vs external

2. How often you release your SDK?

3. How much time it takes a fix a showstopper?

Sample SDK and Sample app 

It will be nice to share the sample code with the clients.

Usage of Third Party Libraries

As much as possible avoid the usage of any third party libraries. If required confirm it before using it. Propose why is it required and why it cannot be avoided.

SDK Size

1) Make sure your sdk size is very optimal and no extra assets in the sdk which is temporary.

https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Frameworks.html#//apple_ref/doc/uid/10000183i

2) https://github.com/google/cocoapods-size

3) https://github.com/firebase/firebase-android-sdk/tree/master/health-metrics/apk-size#readme

4) https://firebase.google.com/docs/android/sdk-metrics