New altool recently (or at least start from Xcode 13.x) is intermittently resulting timeout 1001, ref: https://developer.apple.com/forums/thread/699749.

Solution may be:

• using altool from lower version (e.g: 12.5.1), or
• retry the process until got succeed.

<Soon will re-update if any other problem occurs>

1. Feature Flag / Remote Config

This is a system where we can control the appearance of our features. The best practices (in my opinion) is, we need to add flagging system into each of our features. Usually, it will be handled from their entry point.

So for example, there is button that shown in our homepage. This button, when clicked, it will redirecting user into feature A.

We can give flagging for the appearance of this button. Or also, we can always showing the button, but when it clicked, and if the flag is currently OFF, we can show an alert, something like “sorry, this feature is currently disabled”.

Usually, we’re flagging a feature, and remotely control it appearance, to handle some cases, like:

• When the feature accidentally having a problems, we can turn it OFF
• When the feature is ready on the App side, but the Backend / APIs is not yet ready, so we can turn it OFF, and then when the backend is ready, we can turn it ON.
• When both App and Backend side was ready, but it still waiting for the legal / compliance things, like waiting the agreement to be ready, or the feature is still pending verification by the government. After the compliance is done, we can turn it ON.

There are many tools to supporting this system. The most popular ones (afaik) is Firebase Remote Config. It is free (afaik), and we can handle the flag to be having other values rather than Boolean. Also, we can filter the flag, to be ready on specific build number / version, only for specific platform, or only for some specific device. But, it lack of filtering based on user ID / segments (CMIIW).

Other tools that supporting based on user ID / segments is Leanplum, using service Leanplum Variables.

Or, we can have our system, end to end, from Back End to Front End. And we can customize it based on our need.

2. Handling force update

Force update means, stopping the user journey, when they use certain version. It’s important to handle this things. Usually, we need to do this when some specific versions are too old, or it contains major bugs that can’t be solved by backward compatibility from Back End side. Another reasons may be, we need to do stability on Back End or Front End side, and we need to have minimum versions for our users (so their journey will not blocked).

Usually, force update handled by, Back End checking the app version that used by the user. When it includes in list of App that need to be updated, they will returning status code 410 from many APIs. Then, when the App got that in any APIs, they will show popup or alert to users for updating their App.

3. Handling Force Logout

Sometimes, we need to force user to logout, when uncertain conditions is happen, like token expired for unknown reason, or uncertain bug occurred. It’s not a good journey for them, but better to prepare it on our App, as soon as possible.

Usually, when we want to force user to be logout, in a certain conditions (that already set in our system), Back End will return status code 401 in all APIs, and then App detecting that, and user will be logged off.

4. Giving many fundamental values on the request headers of the request APIs

There are some attributes that need to be sent from App, to identifying current session in user. Some of them are:

• OS Name: for collecting Data, to determine / analyze some patterns
• OS Version: for collecting Data, to determine / analyze some patterns
• Device Model / Type: for collecting Data, to determine / analyze some patterns
• App Version: for collecting Data, to determine / analyze some patterns. Also usually used by parameters of force update
• Authorization: for the credential of the users

5. Monitoring Request Logger

Usually it can be handled by Back End side. So the flow will be, whether Back End returning or receiving API response from App, they will record it into some tools, example: Kibana, Datadog.

But sometimes, Front End can manually record it. So basically, the process would be, when App sending request or receiving response from Back End, they will record it into some tools, like tools above.

Then we can creating dashboard or just querying it, for analysis many things, like uncertain response from Back End, or uncertain parameters values from Front End (combine with some Data that already sent by the App, e.g: OS Version and Device Model).

In my opinion, better to handled it by Backend side, so we can easily customize it sometimes, and it always be backward compatible.

6. Monitoring Crash Performance

Many tools are supporting this. The most popular one (I think?) is Firebase Crashlytics. The purpose is quite simple and obvious, to determine whether a crash is happen on our App, and then we can know what part that triggering it. Usually it also come with many useful data, like OS version, app version, user ID, file and line of the code that triggering the crash, and report time.

I think that’s all that I can tell. There’s still many things that I think every App need to have, like Tracker Event (for analyzing user journey), having design system, and many more. But I think that it can comes in the middle of App Release journey / doesn’t need to be developed from the beginning.

But, on iOS 14.5, our team also facing an UI Bug that only happened on iOS 14.5. The bug is like this:

So basically on this page, we were creating a custom UIAlertController, then we modify the constraint that on it’s child view. The parent view will be adjusted too.

And then in iOS 14.5, looks like there is an update that UIAlertController has different hierarchy of the view.

Not sure also if we previously doing it wrong tho. But after we consider that, and fix the constraint, the UI now works as expected, not only on iOS 14.5, but also on lower version of OS.

Our fixing is something like, remove the parent’s view width constraint, remake the new width constraint, and then applying it both on parent and child views. Also, we adjust the leading anchor constraint on child view based on it’s parent’s view.

Hope it help everyone who may facing it!

• iOS 14.3 simulator with a yellow navigation bar color.
  Ref: https://developer.apple.com/forums/thread/669459.
• UIDatePicker have new behaviour, now it have property datePickerStyle and preferredDatePickerStyle, with some types like .automatic, .compact, .inline, and .wheels. default is .automatic.
  Ref: https://www.andyibanez.com/posts/new-uidatepicker-ios14/ .
• UITableViewCell new behaviour: Need to add the view into contentView of UITableViewCell, not directly into UITableViewCell itself.
  Ref: https://stackoverflow.com/a/63951794.

But, I want to highlight the most important, basic, and essential part regarding this problem. Thanks for https://devgenes.com/posts/ssl-pinning-with-alamofire for highlighting this, I don’t look any other references / authors (yet) whose highlighting this “most and basic essential part” regarding to implementing SSL Pinning with Alamofire.

So yeah, in SessionManager, you need to add the base domain, not including the https://. If you not do this, than the SSL pinning for your App will not works.

Basically, from what I read on https://gist.github.com/hujunfeng/6265995 (thanks hujunfeng!),

• UUID from IDFA (ASIdentifierManager.shared().advertisingIdentifier.uuidString) will remain same for all apps in a device. The value will only changed when user does full reset on the device, or manually reset the advertising idenfifier.
• UUID from IDFV (UIDevice.current.identifierForVendor?.uuidString) will be different for (almost) all apps in a device. I say "almost", because some apps that comes from "same prefix" of Bundle ID (e.g: com.calculator.apps, and com.calculator.apps2) will be have the same UUID IDFV. The value will changed when all of that "same prefix" Bundle ID apps are deleted / uninstalled and then reinstalled.

So that’s it. Now We know which the best for us for defining the “Device ID” of our users.

So, we decide to find other workarounds to solve this. First, we found that we can use Environment Variables in XCode, because we can set it in our project using a script, and then the script will put the secret values based on values in environment variables that we already set in our OS (In our laptop, or in CI).

But, it turns out that it will not works as we expect, because we just realized that environment variables, is only available in our Laptop and CI, not available in our user, in their device, right? https://stackoverflow.com/questions/14214741/xcode-environment-variables-not-present-during-archive

So, we tried to found another ways, to keep it secrets. Then, we found a trick! We store our values in Plist, we ignore it in our Git, and then ditributed it manually into our team.

Then, what about in our CI? We use a hacky ways, we create a script, that will generate the Plist, based on values in Environment Variables in CI, and then run that script only in our CI, so our CI will also have that Plist!

In our CI, we generate first the Plists, using shell script ruby generate_keys.rb, and then run script for building our XCode Projects.

So, both environment (in our Laptop and in our CI) will have that Plist file, and then the building can works successfully! :)

neither the application:didRegisterForRemoteNotificationsWithDeviceToken: method nor the application:didFailToRegisterForRemoteNotificationsWithError: method is called.

When we do some next research, we also found that

on some connections, especially Wi-Fi connection, the port of APNS (5223) may got blocked.

https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/HandlingRemoteNotifications.html#//apple_ref/doc/uid/TP40008194-CH6-SW3

Because of “impossible case to handle” like that, this case may got more attention into our development process. For example, we should exclude the “mandatory push token” into our vital flow, e.g: Login Flow, or educating the users to (maybe) “Switch the internet operator for a while” when getting this condition.

To decreasing the occuring of that condition, we can do some enhancement in our code, related to registering remote push notifications. After discussing with Apple and reading the Leanplum’s documentation, we found out that we can call registerForRemoteNotifications() whenever users are accept or denying the push notifications. Although we register the remote notifications, Apple will still exclude the push notifications into our users, when they rejecting the push notification, so it’s safe to still calling this function. The example code will be like this:

So, just it. Thank you guys for reading this!

Then, we decide to “remove” that script from our xcodeproject, because we think that we don't need that "extra step" to make sure our installed pods is the correct ones. We thought our current setup of Cocoapodsis already good.

Btw, this are our setup of Cocoapods, in our iOS App:

1. Commit Podfile with declare exact version for it's library
2. Git ignore the Podfile.lock
3. Git ignore the folder Pods
4. Always do pod install in the beginning (before compiling the app)

I think we’ll need that script if we’re not doing step 2 and 3.

Then, how we do it (removing the build phase script)? We do that by this script, that called in Fastlane.

You can also remove it by using Podfile, in step post_integrate, like this:

Why we need to do it via script? Because:

• if we do it manually, the script will always appear again after pod install
• we don’t commit the xcodeproject

And this is the result:

Our build success compiled. Since this is still an experiment, I’ll updating this post whenever something unnecessary happened.

This error is caused by renaming the username in Laptop, and the old path is not changed (based on new username). The path still pointing into

“/Users/{OLD_USERNAME}/Library/Caches/com.apple.amp.itmstransporter/obr/2.1.0/com.fasterxml.jackson.module.jackson-module-jaxb-annotations-2.9.8.jar”,

while the new path should be

“/Users/{NEW_USERNAME}/Library/Caches/com.apple.amp.itmstransporter/obr/2.1.0/com.fasterxml.jackson.module.jackson-module-jaxb-annotations-2.9.8.jar”.

To solve this, we just need to remove /Users/{OLD_USERNAME}/Library/Caches/com.apple.amp.itmstransporter entirely. And then just try to re-archive and re-upload into Appstore. Then it will trigger creating the new transporter in the right path, and automatically pointed into the new one.

PS: Thank cleardemon, for posting this info in developer apple forum!