I think the first thing you should know before making an app is about the app’s environment or the life cycle of the app. I know you would probably super excited to make your own app after studying basic grammar but i’m sure the app’s quality or the programming skill will stay the same forever
For example, I have played league of legends since high school and i still suck at it. Tbh, my friends are telling me to quit 🤭 I think the reason i’m being looser is that i don’t really tried to understand every champion’s characteristics, role of each lines, and the flow of the game. but what if I understand those basic things and play the game? I’m sure I won’t be silver forever.
So what I was going to say is, to develop Apple’s product and to use their framework that they have made, we should understand the basic concepts and each one of the characteristics to join and win Apple’s game.
App and Environment
Application interacts between our custom code and system framework. System framework provides the necessary environments that requires for us to run the app. While custom code provides features that we want to provide to the users. In other words, It’s divided into two parts.
- System Framework : where apple provided which means we can’t edit
- Custom Code : where we provide features to user
Main point of entry for an application
Back to our mother language C, all the application starts from the main() function and this is called an Entry point. Since object C is a superset of C programming language, the app still starts from main() function but the main difference is that Xcode provides main() function automatically for us therefore we don’t need to customize the main() function as below.
So how does the main() function works?
main() function accepts two parameters, (int argc, char * argv[] ) and calling UIApplicationMain() method passing accepted parameters and the appDelegateClass.When UIApplicationMain method is called, it will create the application object and the application delegate and set up the event cycle.
So we can think of UIApplicationMain() as the entry point of the app and a run loop that delivers input events to your app. Basically it handles most of the important methods and the entire process of the app such as reading the storyboard and doing initial set ups for the app.
UIApplication is the created application object by UIApplicationMain() and it’s the application itself(root object of the app) but since this is bit complicated to customize, we don’t usually have to work with it. However, there’s time that we need to manage some interactions with the system. That’s the purpose of the App delegate such as,
Most apps don’t need to subclass
UIApplication. Instead, use an app delegate to manage interactions between the system and the app.
- initializing app’s central data structures
- configuring app’s scenes
- Responding to notifications originating from outside the app
- Responding to events that target the app itself, and are not specific to the app’s scenes views or view controller
- Registering for any required services at launch time, such as Apple Push Notification service.
SceneDelegate?
😈 In iOS12 and earlier, Application had one process and also just one user interface instance to match it.
- in iOS 12 and earlier, use the UIApplicationDelegate object to respond to life-cycle events.
😈 In iOS13 +, ipad apps can support multiple windows such as enables document creation, people could have multiple document windows open at the same time. In other words, Applications now still just share one process but may have multiple user interface instances or scene sessions.
- in iOS 13 and later, use UISceneDelegate objects to respond to life-cycle events in a scene-based app
A
UISceneSessionobject manages a unique runtime instance of your scene. When the user adds a new scene to your app, or when you request one programmatically, the system creates a session object to track that scene.
UIAppDelegate took care of everything in iOS 12 and earlier but in iOS13 and later UISceneDelegate will take over some of the roles of the app delegate.
AppDelegate is still responsible for process events and life cycle, but it’s no longer responsible for anything related to your UI life cycle.
Instead, that’ll all be handled by your UIScene Delegate Any UI Setup or teardown work that you used to do in your App Delegate. In other words, It will take care of life cycle events in a scene based app. It is the core methods you use to respond to life cycle events occurring within a scene. object to manage life cycle events in one instance of the app’s user interface.
Scene? Manage multiple instances of the app’s UI simultaneously, and direct resources to the appropriate instance of the UI.
Swift
Anyways, back to the main() function blah blah.. Swift language isn’t the superset language of C. Swift is an independent language developed by Apple. Instead of the main.m file, Swift uses attributes (annotation) to mark a class application’s delegate to provide additional information about the declaration or type.
App’s Life Cycle
The current state of your app determines what it can and cannot do at any time. When the app changes from state to state, UIKit notifies you by calling methods of the appropriate delegate object accordingly (UISceneDelegate, UIApplicationDelegate)
States of an app:
- active: The app is running in the foreground and currently receiving events
- inactive: The app is running in the foreground but is not receiving events
- background: The app is running in the background
👾 Scene-Based Life-Cycle Events: If the app supports scenes, UIKit delivers separate life-cycle events for each. A scene represents one instance of your app’s UI running on a device.
When the user or system requests a new scene for the app, UIKit creates it and puts it in the unattached state. User-requested scenes move quickly to the foreground, where they appear on screen. Use scene transitions to perform the following tasks:
- When UIKit connects a scene to your app, configure your UI and prepare to interact with the user. See Preparing Your UI to Run in the Foreground.
- When transitioning to the foreground-active state, configure your UI and prepare to interact with the user.
- Upon leaving the foreground-active state, save data and quiet your app’s behavior. See Preparing Your UI to Run in the Background.
- Upon entering the background state, finish crucial tasks, free up as much memory as possible, and prepare for your app snapshot. See Preparing Your UI to Run in the Background.
- At scene disconnection, clean up any shared resources associated with the scene.
- In addition to scene-related events, you must also respond to the launch of your app using your
UIApplicationDelegateobject. For information about what to do at app launch, see Responding to the Launch of Your App.
👾 App-Based Life-Cycle Events: UIKit delivers all life-cycle events to the UIApplicationDelegate object. The app delegate manages all of your app’s windows, including those displayed on separate screens. The app transitions to perform the following tasks:
- At launch, initialize your app’s data structures and UI. See Responding to the Launch of Your App.
- At activation, finish configuring your UI and prepare to interact with the user. See Preparing Your UI to Run in the Foreground.
- Upon deactivation, save data and quiet your app’s behavior. See Preparing Your UI to Run in the Background.
- Upon entering the background state, finish crucial tasks, free up as much memory as possible, and prepare for your app snapshot. See Preparing Your UI to Run in the Background.
- At termination, stop all work immediately and release any shared resources. See
applicationWillTerminate(_:).
Please let me know if there’s anything i need to update 🙏🏻 I still need to study in detail but this was a bit hard topic for me so.. i will try to read again and update the post.
references :
