Deployed or Released? Why do you might need a Digital Technical Architect…

I was privileged to work in a team with pretty good engineering culture, and I have seen also the opposite, where the software development team was only seen as a cost center.

Anyhow, if you are in the situation where your company can afford Technical Architect, there are good chances that someone from the Backend team will take the lead on mobile related technical decisions. It can be viable, if that person already has experience in mobile development, or at least openness for listening the mobile developers, otherwise both the end product and the team can suffer from the bad decisions.

Let me jot down a few topics that based on my experience, when coming purely from a Backend experience would surprise the candidates.

Resources

It is easy and cheap running cron job, which reaches out to the network, and also cheap to do retries on almost all of the network calls, when your machine is sitting in a 24/7 data center, with at least 100MB/s bandwidth access to the Internet, and powered with a UPS. If you are using virtualization and you have a software architecture that scales, you can spin up extra virtual CPUs and memory to the rescue in not time (and this can also a help for poorly optimized code as well).

While the mobile processors are soon beating or in par with the notebooks, there are still resource limitations on mobile devices. First of all there is the battery, and there are several services on the mobile are tend to empty the power source of the device. Second of all, due to the limited resources the app lifecycle on the iOS devices doesn’t let you to run whatever you wish when the app is in the background, or the phone is locked. The operating system will schedule the app background operation, and as a developer, we could only give some recommendation to the system when to run it. The operating system is also a good housekeeper in terms of memory management: if your app starts using more memory, and the system decides that the increased memory usage is jeopardize the whole system, it will just kill it. Not the best user experience for your app, but definitely protecting the iOS own user experience.

The last thing is the Internet. I know that now we are in the 5G era, but still: there are people who are using their phones with a few hundred megabyte monthly balance. If your app decide to retry 4 times (silently) the network calls in case of errors, and it happens that the user is uploading a 25MB file, you might have burned 100MB of your user’s mobile internet balance. From my point of view I would be more than angry…

Privacy

When some data is passed on Kafka or RabbitMQ message buses, most of the time the privacy is not really considered. From Backend point of view this data is already acquired, so there is no need for user consent. However on the app whatever data is passed to the backend or 3rd parties should (and in the EU must) be subject of privacy concerns.

For example the usage characteristics of the app, which is essentially the user behavior inside the app, can be revealed from the backend calls and easily be fed to further analysis. This technique should and sometimes must have a user consent before doing so.

The location data, and the assumption that the user can be reached with push notifications are both conditional, most of the time you need to plan with a fallback for such cases when the user doesn’t want to share information, or accept messages from you.

Accessibility

I will be honest, even myself feel guilty, I think I don’t do enough to support this. If someone is seeing the product as just a nicely designed API, there is a bad news: the end users probably never going to interact those APIs. The end user will be using some frontend technology as a middle man between those API and herself. If the end user has any problem which requires using the iOS accessibility tools, you, as a responsible iOS developer should and support it as well. This problem probably never pops up on a backend meeting.

Deployed vs Released

I think that might be one of the biggest factor to influence the ongoing support and drive technical decisions as well. Most of the backend and even web applications are deployed. That means that the code and the machine which runs the code stays in the possession of the developer organization. If there is a code or configuration change is required in those systems, the time to deploy them is solely depends on the organization.

In the other hand the iOS apps are released. That means that both the code and the running machine will be thrown out to the wild, and if the user doesn’t want to update the app, they won’t do. If there are breaking changes in the API, critical bugs or configuration changes, those will never reach your application, and might causing angry customers. For this purpose I usually recommend to put in place a force update mechanism, where you can inform your user that the app is outdated. This feature must be part of the MVP. Also try to push as much of the logic and configuration coming from the backend, so you can leverage from the flexibility mentioned at the deployed services.

Thanks for reading through. I hope I could give you some ideas for your current and future projects, and get further clarity how the backend, and even web frontend technologies are different than the iOS, or mobile development.

You can reach me out on Twitter: petermolnar_hu