How Mobile Apps are Built Around Devices
A few months ago, a friend of mine was talking to me about a mobile game that had become popular, called Animal Crossing Pocket Camp, released by Nintendo. Although they're most well-known for their consoles and portable devices, and the video games meant for them, they had been recently dabbling in mobile development and microtransaction systems. "The game being monetized just turned me off from it," they said, leading them to never play it. I had played it for a short while, however, and told tell them the game's monetization is the least of its problems.
"It can't be that complicated," they responded, "to make a cashgrab like this. What other kinds of 'problems' can they run into?" I thought about it, and realized just how many factors go into monetized systems and mobile applications. Developers have to consider the vast myriad of devices, their specifications, and how the user engages with the app content. Although I'm no expert, and don't know what really is taken into consideration, I broke it down like this:
First is the amount of storage space on the device. A long, elaborate, or content-packed game or app will take up much more space than a simpler app. If an app is going to take up that much space, it needs to be worth it enough for a user to delete enough apps and files for it to fit, or to purchase external storage. Also to consider is if their device doesn't have a way to add external storage, or if the app cannot be moved to external due to permissions, security, or other app requirements.
Then is the remaining device specs. A very intensive game or app can take up most available RAM, preventing a user from doing other tasks during use. When answering phone calls or texts, or otherwise switching apps, the application will shut down in the background. This can be an issue if this is an app that is constantly connected to the internet, and/or has long loading times. A user may be unwilling to open the app when they'd like to because of how much it debilitates their device usage.
Other resources that have to be considered are battery usage, data usage, and device feature usage. The amount of battery can cause a user to be tethered to their charging cord, and not be able to use it on the go. Data usage can block or limit usage to users with a small data plan, or whose device can only use Wi-Fi, which they may not have reliable access to. Some older or simpler devices lack some features that may be considered basic, like front-facing and/or backfacing cameras, flashlights, gyroscopes, multitouch, or vibration. And any of these requirements can be further blocked by app permissions or parental controls.
When this hurdle is jumped, or if a large enough user pool can put up with the app requirements, then the app must deliver an experience that makes those requirements worth it. If it's a game, then game content, length, and engagement are important. If a functional app, then its functionality is key. This leads into another detail, which is how much time a user will use on an app. For monetized games, a user who is unwilling or unable to make in-app purchases will be forced to actively play or wait for a long time to obtain substantial resources for free. This can cause the game to completely monopolize their time. Either the game needs to be engaging and interesting enough for someone to devote that much time, or provide reasonable means of skipping the line. In-app purchases serve this purpose, by allowing one to pay to save time. Determining the right scale of pricing for the amount of time saved is a difficult task.
Other resources that have to be considered are battery usage, data usage, and device feature usage. The amount of battery can cause a user to be tethered to their charging cord, and not be able to use it on the go. Data usage can block or limit usage to users with a small data plan, or whose device can only use Wi-Fi, which they may not have reliable access to. Some older or simpler devices lack some features that may be considered basic, like front-facing and/or backfacing cameras, flashlights, gyroscopes, multitouch, or vibration. And any of these requirements can be further blocked by app permissions or parental controls.
When this hurdle is jumped, or if a large enough user pool can put up with the app requirements, then the app must deliver an experience that makes those requirements worth it. If it's a game, then game content, length, and engagement are important. If a functional app, then its functionality is key. This leads into another detail, which is how much time a user will use on an app. For monetized games, a user who is unwilling or unable to make in-app purchases will be forced to actively play or wait for a long time to obtain substantial resources for free. This can cause the game to completely monopolize their time. Either the game needs to be engaging and interesting enough for someone to devote that much time, or provide reasonable means of skipping the line. In-app purchases serve this purpose, by allowing one to pay to save time. Determining the right scale of pricing for the amount of time saved is a difficult task.
One of the best ways I've heard it explained is like this: In x amount of hours of play, how much currency can you accrue? Take that amount and divide it by the time, and that's like wage an hour. Now, how much do you make at your job? Far more, likely. So, spending some of your real-life wage allows you to make the same amount of progress in far less time than for free. So is it more worth your time, or your money?
I told all this to my friend, and they were astounded by how complicated mobile applications are from a business perspective. They mentioned another game, called Team Kirby Clash Deluxe. It was released on 3DS by HAL Laboratory, an affiliate of Nintendo. "Well, this game is on a device that's made for video games," they said. "You don't have to worry about specs with this. So that means it's probably better, right?" That's not necessarily the case, I explained, because all of the above factors are a hard balance to strike. Even if only one of them is an issue, it can make or break the game or app for a potential user. Pricing and time monopolization were that particular game's problem.
Although it isn't an example of a monetized game, I then told my friend about a third game, called Part Time UFO, also released by HAL. Within a few hours, it quickly tops the charts for Top Paid Action games on iOS and Android. What made it so immediately popular, besides being the first mobile release of a trusted name, was that it was built for the devices it was meant for. It has a small app size, isn't greatly intensive, and has no in-app purchases, being priced at $4 outright. Besides that, the game itself is simple, charming, and well-stylized. That's not to say this is the 'right' way to develop an app for mobile devices - this game plays it safe. And my friend started to understand where I was coming from.
They praised me, saying I must be learning a lot about my field. But my understanding has nothing to do with IT. I even told them, "I never learned anything like this." All it took was a little extra thinking, and my own casual experience with various apps and devices. When I do learn about the process and considerations, I'd like to see how close I was.
They praised me, saying I must be learning a lot about my field. But my understanding has nothing to do with IT. I even told them, "I never learned anything like this." All it took was a little extra thinking, and my own casual experience with various apps and devices. When I do learn about the process and considerations, I'd like to see how close I was.
Comments
Post a Comment