It appears as though Apple has reached an agreement with the parties in a class action regarding Apple’s App Store policies. Here are the highlights:
The Small Business program will remain enforce for at leas the next three years.
Search results will continue to be based on objective characteristics, like download numbers and text relevance.
Developers can inform customers outside of their apps that they can purchase subscriptions and the like at a lower price.
The number of price points will increase to over 500, from the fewer than 100 now.
The option to appeal a rejection will be maintained.
Apple will provide a yearly transparency report.
A $100 million fund will be established to assist developers.
The proposed settlement has only two real changes, the additional price points and the fund. Outside of that, there is no real change. In reality, this does not cost Apple anything. Most of the proposed settlement items were already in place.
Sure, Apple will have to spend money and resources to enable the additional price points. And the $100 million fund for U.S. developers will cost money, but in the grand scheme of how much Apple makes, $100 million is not a whole lot, particularly since Apple made $21 billion in profit in the March to June quarter this year alone.
This settlement is laughable given that there will be no meaningful changes. This does not really address some of the underlying issues like arbitrary interpretation of App Store rules and spurious rejections.
Apple will get to continue their existing practices which ultimately end up benefiting them and not developers.
I have been thinking about the ‘Hey’ app controversy that has been happening this week. I was not sure if I was going to post about it, but I have decided I have thing to say about it. I will not go in-depth into the situation. There are others that have done a much better job than I could.
If you want to read the start of it, you can begin with the original Twitter thread from Basecamp’s co-founder, and Chief Technology Office, David Heinemeier Hansson. The first tweet is below and clicking on it will show the entire thread.
For more comprehensive coverage, check out a TechCrunch piece by Sarah Perez and an interview with Apple’s Senior Vice President of Worldwide Marketing, Phil Schiller TechCrunch’s Matthew Panzarino. Despite the more expansive coverage by others, a brief summary is needed.
To summarize the issue, Apple is refusing to allow an update for Basecamp’s ‘Hey’ email app, without Basecamp implementing in-app purchasing for subscriptions. Doing so allows Apple to get their 30% cut of the subscription fee. I have some thoughts on this as an independent developer.
First, this entire situation should be terrifying for all developers. The amount of power that Apple has over the App Store is absolute. They can make or break an independent developer. If Apple is willing to pick on a large developer, then what chance does a small and independent developer have? Ben Thompson, of Stratechery, has heard from numerous companies, “from the smallest companies in the world to the largest”, about how they have been subjected to the same demands as Basecamp, so this is not a one-off situation.
Second, this is very bad from an optics standpoint. Former technology journalist, and super smart techie, Christina Warren sums it up quite nicely:
This is a complete and utter shit show, plain and simple. There have been many examples of Apple doing things that go against the interest of developers. Sometimes these are in the names of customer privacy, which is to be lauded, yet in other situations, the actions are just plainly against the developer.
Third, the timing of this could not have been worse. If this had been, say November, it might not get as much attention, but this is the week before Apple’s World Wide Developer Conference. The week prior to, and of WWDC, the focus is on Apple, its developers, and the new releases. Furthermore, the response from Apple became a focus of the technology community on the same day that the European Union began investigating Apple for its App Store practices.
What did not help was the tone of the response to Basecamp. As Ben Thompson and John Gruber stated on their June 19th episode of their podcast Dithering, typically “Apple is a measure twice and cut once company”, also stated, and I am paraphrasing, “it could be that Apple felt pressure to respond” as to not have the story continue into WWDC week, when they want the focus to be on the new releases.
From Ben Thompson’s June 18th Stratechery newsletter:
Everyone else is absolutely terrified of Apple — again, from the smallest companies in the world to the largest.
In fact, I would go so far as to say that executives in the tech industry are more afraid of Apple in 2020 than they were of Microsoft two decades ago. App Store Review is such an absolute gatekeeper, and the number of ways that Apple can retaliate are so varied and hard to verify, that no one is willing to publicly breathe a word against the company.
This last sentence is the part that I think is the most problematic. Microsoft had quite a strong hold on the internet browser market in the mid-1990s that it was difficult for anyone else to make a dent into the market, because the browser was built into the operating system with no way to uninstall. I would venture to say that their stranglehold is somewhat similar to the way that Google has used its dominate market position to force changes that go against the open web standards, but that is a different topic entirely. The result of these practices was the infamous Microsoft was an anti-trust trial that resulted in Microsoft having to unbundle their internet browser from the operating system and provide users with alternatives. It it unknown what a similar trial for Apple would result in.
The arbitrary nature of the App Store approval process is not new. Many Apple developers have stated that sometimes it comes to the luck of the draw as to whether or not your app will get rejected for any reason. This is due to the “Monday Morning Reviewer” syndrome and the whims of the reviewer. For instance, you could submit your app for approval, have it get rejected for some reason, make a minor change or no change at all except for a build number, then resubmit and it will be approved. This shows the arbitrary nature of the App Store reviewers and the inconsistencies between them.
Lastly, many have stated that Apple’s priorities are as follows:
This seems to be borne out in practice. Apple is first and foremost a public company. Their valuation depends on investors paying more for shares of the company and their primary focus is making more money. Customers coming second also makes sense, because Apple cannot make money without customers.
However, having developers being last does not always make sense. I think Apple forgets that a vast majority of its developers, 99.9%, are also their customers, just as much as their non-developer customers are their customers. Developers, who have inarguably helped build the App Store and Apple into the company that they are today, are the same ones who buy Apple’s products. They have to do so, in order to build an app and have it in the App Store. Outside of this, developers are often the ones telling their friends and family to purchase Apple products and bringing people into the Apple ecosystem. The reason that they do this is not just because they are developers, but because they also enjoy using the products.
What I think Apple seems to forget is that yes, they built the platform, however it is is the developers who have created the apps in the App Store. The apps have driven demand for Apple’s products and the App Store in general. I understand that Apple has seen falling demand for the physical products and wants to wants/needs to shift to services as their primary source of revenue. This approach makes sense, but not to the extent where it will begin pushing developers to think about releasing new apps and I honestly could see some developers opting for other platforms and foregoing Apple’s platforms entirely.
Furthermore, I would not be surprised if we starting seeing MORE apps that utilize cross-platform frameworks, like Electron, instead of fewer. The reason I think this is because if a developer uses one of these and Apple decides that they want to pull their app from the store, then their development workflow does not change much and they still can make money from their work. This results in a worse experience, but when you are at the whims of an arbitrary set of rules, you may not have a choice.
If you ask any developer who has been building apps for the App Store for any length of time to describe an instance when their app was rejected, each and every developer would invariably have an example to share. I am no exception to this.
I will state outright that I do not make my primary living from the App Store. The amount I have made from the App Store does not even cover the developer fees that I have paid. Even with that though, I still do have two apps on the App Store, and I also use my developer account to be able to download and install beta releases of Apple’s platforms, for my books, so I do rely on my developer account. I have been paying for my Apple Developer account since 2008 when the iOS SDK was announced, so I am not a newbie to the App Store and the Apple developer community. This entire situation makes me quite hesitant to develop any new applications, because they can be rejected for any reason, and at any point. It is not likely that Apple would remove an already published app from the store, but it has been done.
Since my app has been on the App Store for over 10 years, I have had my fair share of app rejections. Most of these were due to mistakes on my end (like app crashes and buttons not working, or missing metadata, missing entitlements, and other minor blunders), but two that I can think of right now, were not. The first instance was when my App was rejected because Apple wanted to ask about how I used a specific feature. Instead of just putting a hold on the release, they outright rejected the app. No developer likes to have their application rejected and having it rejected for something like this seems counter-intuitive.
The second, and more time consuming issue, was when I was forced to change the name of my ad-supported app, because it contained the word “free” in the name. The app had been in the store for 8 years at that point and there was no issue up until that point. This is a prime example of rule re-interpretation. Neither of these really impacted my revenue since my app has had $635 in total sales since being released in 2010. The time consuming aspect was not the fact that the name had to be changed, but this version is the one where I introduced app icons. This caused me extensive amounts of time. First, I had to come up with a new name. Next I had to make the necessary code changes, re-create the icons, and then re-import all of them. Each icon had to be individually imported and with 14 icons and 18 different sizes for each one, this meant 252 individual icons that needed to be imported. Needless to say it was a lot of work for a change that did not need to be done, except on the whims of an Apple App Store decision.
I do have an idea, which might be a compromise, but would take significant work on Apple’s part. Right now there is no way to side-load an app onto iOS. I think Apple should create the ability to do so. This could, and should be, in the same manner as macOS apps that cannot, or their developers prefer not, to have them on the Mac App Store. In other words they need to be notarized.
These apps would still get the same protections that apps on MacOS get, in that they will be checked for malicious code, individual app versions can be removed. Additionally, these apps could be distributed outside of the App Store. With this approach, these apps could be allowed to use their own payment processing, but they would still be protected by the App Store. Sandboxing can be enforced and required. Alternatively, maybe it does go through a full App Store review, and a downloadable, distributable version that is counter-signed by Apple is provided.
This could be a special type of app that would not be allowed to be distributed on the App Store and it would still need to be verified before it can run. This would require significant work for Apple, not only on the App Store side, but also on iOS. They would have to build the ability to side-load apps onto iOS, which is not available now.
I do not claim that this is the best approach and I am sure that I am missing somethings that could cause the idea to not be a worthwhile pursuit, but it is something that can be looked into. It would mean additional work for users to obtain these. However, all around it could allow developers to be able to provide their apps in a secure manner and the slight relaxation of the rules for these apps would generate good will amongst developers and users.
Even if Apple were to begin working on this now and make it a priority, it will likely be a year before we will see this come to fruition. However, considering the amount of time that things like this take, it would not be something we would see for years.
I do not think this is a one-off situation, nor the last time that this type of controversy will erupt. There have been rumblings that Apple specifically targets popular developers to make examples of them, specifically because of the popularity of the app. The developers often do not have any choice but to comply. In this particular case, Basecamp is not complying, they are going to fight.
While I understand that the App Store rules are intentionally not black and white, as to allow some interpretation, and that the rules do not explicitly state what is allowed versus not allowed, in this case I do think Apple is making a mistake by not applying the rules consistently. This line from Apple’s response to Basecamp is contrary to what they are doing:
We are happy to continue to support you in your app business and offer you the solutions to provide your services for free — so long as you follow and respect the same App Store Review Guidelines and terms that all developers must follow.
There has not been consistency and enforcement of the rules. There are big companies who can get away with many things without having their apps pulled and their developer accounts cancelled. One big example is Facebook. They used background APIs to listen as well as always track users. At the same time, if a small developer did this, their app was removed and their developer account cancelled.
Sadly, I do not think Apple will be changing its mind on this. I think it will come down to Apple’s hand being forced by laws and rulings that they are compelled to comply with in order for there to be any meaningful change. Unfortunately, this is not a fast process and it will take time for the investigation by the European Union to conclude. Getting a law passed in the United States, in the current political climate, is not likely either. This means that many developers will likely have no choice but comply with Apple’s demands or face losing their livelihoods.
As is the case with many other developers, I am somewhat concerned about talking about the topic for fear that Apple will find it, read it, and not like what I have posted and then remove my developer account, but as you can see, I did post the article.
It is not often that a major shift in technology occurs. Generally, changes are incremental, but there are those times when a big shift does occur. One of those shifts was in 2007 with the release of the original iPhone. As compared to today’s iPhones and iPads, the original iPhone was very basic.
Even with the limited functionality of its day, the iPhone completely changed the course of technology and help usher in the idea of having a computer in your pocket. People generally do not think about that, but you really do have a computer in your pocket. In 2008, the iPhone got a huge boost with the release of a Developer Software Development Kit (SDK). This allowed third-party developers to build applications specifically for the device.
I did not have any application ideas until March of 2010 after Apple announced a whole new product, the iPad. The iPad took the best of the iPhone and put it into a 9.7-inch device. Once the iPad was announced, I had an idea for an app. I called it wwrite.
Once the iPad SDK was available I began building my app in hopes of having it be on sale the day the iPad was released, which was April 3rd, 2010. Unfortunately, I was a bit late and wwrite was not available until April 12th, 2010. I opted to sell my app for $1.99.
In December of 2010, I released a a free version of the app, called wwriteFree, and later renamed to wwriteLite. This was an ad-supported version and initially used Apple’s now defunct iAd platform, but in 2018, I changed this to be first-party ads that I am in complete control of.
I did have a third version of the app available from March of 2011 to August of 2014 called “wwrite – iPhone Edition” this was a version of wwrite that was optimized for the iPhone. I removed this version because it did not make sense to keep maintaining it. With version 3.0.0, released in May of 2017, I switched both apps to be universal, which has made it a bit easier to maintain them.
I thought I would provide a look at how well the app has done over the last 10 years. We will look at a few different aspects and all of the information provided will be accurate numbers. As a couple of notes, the “wwrite” category includes both the wwrite app as well as the now defunct “wwrite – iPhone Edition”.
wwrite – iPhone Edition
When the iPad was initially launched, there was no such thing as adaptive layouts, different screen sizes, and auto layout. There were only two screen resolutions that you needed to worry about, 320 x 480 for iPhone and iPod touch, and 1024 × 768 for the iPad. In order to make my life easier, I thought I would create an iPhone version of wwrite. This would take all of the features of the iPad version of wwrite and make them available on the iPhone.
I initially launched wwrite – iPhone Edition in September of 2010, did one update in 2011, but removed the app from sale in August of 2014, because I knew I was not going to update the app, so I did not want to keep it in the store. By this time there were universal iOS apps and it did not make sense to have such an old app still available for purchase.
When I went to submit version 4.0.0 of wwrite and wwriteFree, the wwriteFree app was rejected, which is not unheard of as apps are rejected quite often. Some of these are due to crashes, as was the case with my initial 1.0.0 release, and has been in many versions after. There is also the possibility that Apple inquires about why you are using a specific feature. This could be because they want to gain additional information, or for some other reason.
My app was rejected because of the word “free” in the name. Now, my app had the same name for 8 1/2 years at that point, so it seemed odd to have to change it. But that is the way of Apple. They did not want any words that reflected the price of the app in the name of the app. Normally, this would not bother me. I would have needed to update my logo, once I came up with a new name, but I had added a whole bunch of different icons, so I had to redo all of those, 14 in total. With 18 different sizes needed for each one, that was a total of 252 icons that needed to be added. Ergo, I was a bit annoyed. I renamed the app to wwriteLite, since I could not come up with a different name. I was inspired by the name scheme of PCalc and PCalc Lite, both by James Thomson.
Shifting Business Models
wwriteLite, now formerly wwriteFree, has been available since December of 2010. wwriteLite was supported through iAds during the life of iAds, which was June of 2016. During the lifetime of my apps, there was a period of approximately 3 years where I did not work on the apps, and they remained as is. This was from June of 2014 to May of 2017. As is noted in my post App Updates and Model Changes, developer James Thomson, creator of PCalc, was the imperious for me to work on my apps again.
As also mentioned in that post, when I decided to work on my apps again, I went with the idea of “wwriteLite” being behind in features, as compared to wwrite. I abandoned that idea in November of 2017 as noted in my wwrite and wwriteFree Updates and Changes post. Instead of lagging behind in features, which honestly would just have been more of a headache for me, I opted to go back to the ad model. Inspired by Marco Arment’s Overcast, I opted to go with first-party ads.
These ads are entirely created, and selected, by me. A majority of the links are advertising my books, but there are also links to movies. These links are affiliate links, so I do make a bit of money if someone clicks on the links and purchases the items. Of course, if anyone buys my books, I make that amount as well.
As of wwriteLite 4.6.0, I added an in-app purchase to remove the ads from the app. As of right now, there has been a total of 1 in-app purchase of this. That purchase was me, on a separate account to verify that the purchasing was indeed working. It is with version 5.0.0 that I created an ad that would bring you to the In-app purchase screen. So I am hoping that creating this will help more users realize there is an in-app purchase to remove ads, and hopefully they will purchase it.
Free vs. Paid
It should come as no surprise that if you compare a free app to a paid one, it is more likely that the free app will have more units sold than the paid. That is definitely the case for me. Specifically, I have “sold” 9,030 copies of wwriteLite and a combined total of 327 of wwrite and wwrite – iPhone Edition. This means that 96.38% of all “sales” have been for the free version.
The total sales for all of the apps is $629. With Apple’s 30% cut, my actual income has been $430. This is not 70%, but with exchange rates, the amount will be different. That is an average of $3.58 per month. Needless to say, my app is not one that I have gotten rich off of, nor is it one that is a viable business.
Most application developers like to know who is using their apps as well as what devices they are using it on. I am no exception. However, I do not need to know exactly who my users are, just some basic information. This includes a user device id, device type, iOS version, app version, appearance (light or dark), the date it was added to the database, and the last time it was updated.
It is not super easy for me to determine how many active users there are with my app. But from my internal analytics, there are 50 users who have opened wwriteLite this year, and 10 who have opened wwrite this year. So this is 60 total, Here is a breakdown of device type:
iPad Pro 10.5-inch (WiFi)
iPad 6th Gen (WiFi)
iPad Air 10.5-inch (WiFi)
iPad Air 10.5-inch (WiFi)
iPad Air (WiFi)
iPad Mini 4 (WiFi)
iPad Pro 12.9-inch 3rd Gen (Cellular)
iPad Air (GSM)
iPad Air 2 (WiFi)
iPad Air 2 (Cellular)
iPad Pro 9.7-inch (Cellular)
iPad Pro 12.9-inch (WiFi)
iPad Pro 12.9-inch (Cellular)
iPad Pro 10.5-inch (Cellular)
iPad 6th Gen (Cellular)
iPad Pro 11-inch (Cellular)
iPad Pro 12.9-inch 3rd Gen (WiFi)
iPhone XS Max
iPhone 11 Pro
iPhone 11 Pro Max
iPhone 7 Plus
iPhone 7 Plus
iPod Touch 7th Gen
Here is a chart of the breakdown of device type.
Starting with version 4.5.0, I added the ability to choose which appearance mode you wanted, “light” or “dark”. Here is a breakdown of version number, the number of users using the “light” appearance, versus the “dark” appearance.
Between my two apps there are 37 devices using the “Light” appearance, 23 devices using the “Dark” appearance, and 4 people still using iOS 12. So this breaks down to 57.8 %, 35.9%, and 6.3% respectively.
This breakdown is merely an interesting statistic, because I will be supporting both “Light” and “Dark” appearances in the app going forward.
It is interesting to see where apps are being downloaded. Here is a breakdown of every “purchase” of wwrite and wwriteLite since 2010. This is in order by number of units from most to least.
This is an interesting list because it shows where I should focus for internationalization. Neither wwrite nor wwriteLite are in any language other than English. This may change in the future.
For those who might like a more visual representation, here is a chart of the top 6 and the remaining countries.
The landscape for apps has become more and more competitive as time has gone on. Here is breakdown of app units by year:
As you can see, the number of units sold, or downloaded, has been going down precipitously since 2013. I cannot say why this has been the case. It could have been due to the fact that my apps were not updated to support iOS 7, which was a major visual change.
I also think part of the issue is that my app has never been a “cloud” app, meaning that it does not support syncing. However, it does support import to, and exporting from, the Files app. This has become significantly easier with version 5.0. On that topic, let us look at some of the big changes with the new version
Through the Years
The App Store, and my apps, have seen significant changes over the last 10 years. Here is a slideshow of various versions of the apps over the past 10 years.
Application development can sometimes fall into a cadence. For me, it has become
Create an update in the Spring before WWDC, because I will be writing books and those take up my time during the summer months.
Create an update in September when the new version of iOS is released to incorporate new features with the new operating systems.
There may be minor updates to fix bugs, particularly crashing ones, but I try to avoid these. I may also do updates if I come up with a new feature I want to add.
I will not go into all of the changes, but you can look at the change log to see all of the changes. However, I will highlight a few of the biggest ones.
There are 5 new icons, Green, Moon, Orange Gradient, Psychedelic, and Sun
Customize Templates now allows you to choose from over 340 colors instead of having to define it yourself.
Files now have actions, including duplicate file, and share file.
There is now Trackpad and mouse support (requires iOS 13.4 or newer).
With having been doing iOS app development for 10 years, there are some things that I have learned over the years, and I thought I would share them.
I have learned a few lessons over the last 10 years of iOS development.
The first lesson is that there are likely plenty of competitors doing the same thing that you are. Therefore, you must try and do something that is unique and that other developers are not doing. For my apps, there are a few apps that immediately come to mind that are similar to mine. Some of these are Apple’s Notes app, Bear, and Drafts. They all have more features, like syncing, rich text, URL support, and more. My app is a plain-text app that allows you to do templates. I support some things, like importing and exporting, but the rich text, url support, and syncing is not included.
Th second lesson is that I am not that good at marketing. I do not like to tout my own apps that often, for fear of annoying others. I do some marketing through my blog posts, but very few see these. There are other I do not use Apple’s Search Ads, because the app does not make enough money to warrant using search ads to gain exposure.
The third lesson is “Keep Developing”. If you really believe in your app, be sure to keep developing it. The updates that you do could just be small updates that merely keep compatibility with the latest versions of iOS and adopt new techniques. The biggest of these was the iOS 7 transition where the entire interface for iOS changed. Updating my apps for iOS 7 would have been a major undertaking and it was tough enough just trying to get my Mac OS X 10.9 Mavericks book done. I did not even write a book about iOS 7.
Not keeping up with development is entirely my fault. I did not develop the app for almost 3 years. I am sure this significantly hurt any chance of, to use silicon valley speak, “staying relevant”. This is entirely on me. There are two things related to this. The first is that I lost interest in development. Maintaining an app is not a simple thing. It requires significant effort to do.
The fourth lesson is to use GitHub, or some other Source Control system, although right now it is likely to be GitHub. This is because GitHub is directly integrated into Xcode. This will make things much easier because you will be able to keep your source code off-site, to avoid the risk of something catastrophic from occurring. I did not lose any of my source code, but I no longer have all of the versions of my source code. I do have the original code for version 1.0 of wwrite. Looking back now, the code is very simple but it worked.
The fifth lesson learned is do not feel afraid of refactoring old code. Code, and techniques change over time. Sometimes you find a better way of doing something and when you do, definitely take this path, provided it allows the following:
Your code is easier to maintain.
Your code becomes easier to read, which makes your code easier to maintain.
My code is now a mix of Swift and Objective-C. There is more Swift code than Objective-C code, but I do have a mix of both. Do not be afraid of adopting new languages. Yes, it will take time to learn, but sometimes it will make things a lot easier to code. At least I have found that Swift is easier for me to code.
The sixth lesson that I learned is to name your app something that is searchable. The name I have for my paid app, wwrite, is not really a good one. wwriteFree, and wwriteLite, are a bit more memorable and are not easily misspelled. I have contemplated changing the name of my apps but the apps are not my primary means of income, so it does not make sense to change them at this point.
The last lesson is that it is okay to put an app into maintenance mode and limit the amount of time you spend on an app. There are definitely instances where it no longer makes sense to continue putting significant effort towards an app. Determining the time is entirely up to you.
wwrite and wwriteLite will likely never be the “killer” apps that will allow me to retire on their sales. There are likely many reasons for this, and they are summarized in the Lessons section above. I do have one addition thing to add to points three and six above.
As mentioned above, not developing my app for almost 3 years probably hurt it significantly. However, the effort that I would have used for app development I put towards my books instead. That decision was a much better one. The amount of money I made with the books just from September 2014 to May of 2015 was twice as much as my apps have made in their entire lifetimes.
Even though I will never “get rich” off of the app, I will continue to develop them. Even though there are very few people who use them these days, the apps have become my playground to keep up with changes in iOS and figuring out how to implement new features of each version of iOS.
Maybe one day I will come up with another app idea, but in the interim, I will continue to work on these apps and maybe, possibly, see an increase in users.
Earlier this week Apple adjusted some of its App Store Guidelines. There have been some changes surrounding prompting for App Store reviews, Sign-in With Apple, building against the iOS 13 SDK, Push Notifications, and certain app categories. The latter two are the ones I want to focus on.
One area where users often complain is in regards to the push notifications that they receive from apps. While you can control whether or not you receive push notifications from an app, it is often not possible to specify the type of notifications that you receive.
The ability for some apps to be able to advertise to their users is paramount. Often this is done via in-app ads. However, other times this is done via push notifications. This can not only detract from a user’s overall experience, it goes against Apple’s App Store guidelines. The guidelines have now been modified
Push Notifications should not be used for promotions or direct marketing purposes unless customers have explicitly opted in to receive them via consent language displayed in your app’s UI, and you provide a method in your app for a user to opt out from receiving such messages.
This is a welcome change for both users and app developers. App developers will be able to advertise to users who actually choose to hear about new products and possible services. If you have an app that users enjoy and you have a new offering they will likely be more receptive to the new product.
My concern about this rule is that it will not be enforced as strictly that it should be. It is my opinion that Apple should give an app maybe two or three chances before pulling the app from the store. Repeatedly violating this app should result in a permanent ban of the app, if not the developer account. This would show app developers that Apple is serious about enforcing the rule.
There is another change that I think might have another angle that most would expect.
Section 4.3 of the App Store Guidelines states:
Also avoid piling on to a category that is already saturated; the App Store has enough fart, burp, flashlight, fortune telling, dating, and Kama Sutra apps, etc. already. We will reject these apps unless they provide a unique, high-quality experience. Spamming the store may lead to your removal from the Developer Program.
The first few apps: fart, burp, flashlight, and fortune telling apps are very simple and easy to make and really do not provide much value. Dating apps on the other hand can provide new and innovative experiences. However, many of them are just simply slightly tweaked takes on the “swipe left or right”.
I think there is another aspect to dating apps that most might not think about. For dating apps you provide a significant amount of information like location, photos, interests and the like. This information, when linked to email address, can easily identify someone and this information can be provided to third-parties which then can be used to target you. Additionally, if the information gets into the hands of a nefarious entity, the information could be used against you.
I think this is why there is the line “unless they provide a unique, high-quality experience”. I interpret this to mean that if a company like Twitter or Facebook were to want to release a dating app, it would likely be approved, but if a company called “ACME Dating app” were to try and release a dating app, it likely would be rejected.
The guidelines that govern the App Store are adjusted from time to time to reflect changes in society and trends in the App Store. The adjustments that Apple has made are changes that could improve the experience for everyone, provided that they enforce the changes like advertising within Push Notifications. Ultimately, only time will tell if the changes will ultimately help or hinder the experience of users.
From time to time Apple updates the requirements for submitting applications to the App Store. Apple has done so again. Starting tomorrow, March 27th, 2019, all new application submissions, as well as app updates, will have some new requirements.
Any app submission will need to be built against the iOS 12.1 SDK, or newer. As part of this requirement, new submissions will require screenshots for the iPhone XS as well as the iPad Pro, if the app is universal.
If you develop watchOS apps, there are also new requirements as well. All watchOS updates will need to be built against the watchOS 5.1 SDK as well as supporting the Apple Watch Series 4.
There is one last item to be aware of, regarding your apps. iOS 12 has changed the way that the amount of memory your app uses. Under iOS 11, if your app used purgeable, nonvolatile memory, the resources you allocated were not counted against your application’s memory usage. This changed in iOS 12. Now, all of the memory that your app allocates will count against its limit. And if your app exceeds the limit, it will likely be terminated.
Many applications already meet these requirements, but if your application does not, it is something to be cognizant of, and you will have to meet the requirements, otherwise your application will be rejected.