Apps wwrite

wwrite 6.0 and wwriteLite 6.0 Now Available

With the release of iOS 14 today, there are new versions of my iOS apps, wwrite and wwriteLite. Both of the apps have the same set of changes:

New Features

  • Requires iOS 14.
  • New free Icons “Halo” and “Sketch”.
  • New icon set “Space” (In-App Purchase). This icon pack is $0.99, or the equivalent in your country.
  • New menus for “New File”, “Tools”, and “Archives”.
  • New Screens for FAQs and ChangeLog.


  • Updated Template Color Picker to use built-in color picker in iOS 14.

Both of these are free updates and are available now. If you experience any issues with the updates, definitely let me know by going to Tools -> Support and contact me via email or Twitter.


Apple Extends Deadlines for Developers

When Apple initially released iOS 13 and macOS Catalina, they had anticipated that they had provided developers enough time to comply with some requirements. These are:

  • Apps must be built with the iOS 13 SDK, and use a Storyboard for the launch screen
  • iPhone apps must support all iPhone screen sizes and iPad apps must support all iPad sizes
  • Apple Watch apps need to be built with the watchOS 6 SDK
  • Apps that support third-party sign-on services must also support Sign-In With Apple

Initially, Apple had wanted to have these in place by March 31st, 2020. However, due to Covid-19, many developers may not be able to accomplish this in the allotted time. Because of this, Apple has extended the deadline until June 30th, 2020.

If you are a developer, be sure to comply with these changes by June 30th, otherwise your app may get removed from the App Store.

Source: Apple Developer

Apple iOS iTunes Mac

Apple iTunes Affiliate Program Changes

Earlier this week Apple sent out an email to affiliate members indicating some changes that will be taking place as of October 1st. Here is the email that was sent:

Thank you for participating in the affiliate program for apps. With the launch of the new App Store on both iOS and macOS and their increased methods of app discovery, we will be removing apps from the affiliate program. Starting on October 1st, 2018, commissions for iOS and Mac apps and in-app content will be removed from the program. All other content types (music, movies, books, and TV) remain in the affiliate program.

This will have some impact on some websites who rely on affiliate links from iOS apps, Mac apps, and in-app purchases to run their business. At least there is some heads up on this. This has been preceded by Apple reducing the payout from 7% to 2.5%. So it was inevitable that this would be the case that these would be removed.

I am not impact much by this because the website does not rely on affiliate links. I am curious to see how long the affiliate program lasts overall. I would not be surprised if it goes away in the future. It may take a couple of years, but it is possible that it will be stopped in the future.

Apple iPhone

Apps and Battery Usage on iPhone

There are many different things that users complain about regarding their iPhones. The biggest complaint that many users have had in that their iOS devices seem to be losing a significant amount of battery, even when using a brand new phone. This has lead to users complaining to Apple. One of the things that Apple has done with multi-tasking is to pause applications when they are in the background. There are certain situations where this does not occur. These include background app-refreshing, background audio, Voice over iP (VoIP), or GPS.

Sometimes, it is so bad that some users purposefully force quit applications in order to preserve battery. Users do this despite there being no practical reason to do so. However, maybe users who do this may not be too far off the mark.

Last week it was uncovered that Facebook’s iOS application was using a significant amount of battery even when users were not actively using the application.

Bruce Geerdes on Twitter has this tweet:

Within the image, 13% of all battery usage for the last week was due to audio. Now, why is Facebook’s app even using background audio? It is not a streaming any audio what-so-ever.

As Federico Viticci states in his piece on

My guess is that Facebook is hijacking audio sessions on iOS by keeping silent audio in the background whenever a video plays in the app. And because, by default, videos on Facebook auto-play on both Wi-Fi and Cellular and few people ever bother to turn it off, that means there’s a high chance the Facebook app will always find a way to play a video, keep audio in the background, and consume energy to perform background tasks.

I think Federico is spot on with this presumption. Facebook is the world’s largest social network, and how do you make sure that your users are “always up to date”, play silent audio in the background so the application can auto-refresh without consequence, that’s how.

When questioned, Facebook stated they were “looking into” the issue, and subsequently Facebook has informed TechCrunch that they are working on a “fix”.

This is all well and good, but I think Apple should take a stance and remove the Facebook application from the iOS App store. This gesture would make it abundantly clear that Apple will not tolerate user-hostile actions like this from any developer, including the world’s biggest social network. Removing the application would likely have some ramifications on users because they would not be able to download the application, but it would send a very strong signal.

Do I think this will happen? In a word, no. I do not think Apple is willing to remove the largest social network’s application from its App Store. However, I think Apple could do a couple of things to make sure that no application is able to do this in the future, not even Facebook.

The first is do some additional testing for any applications. See what usage they have after a set amount of time. I would not expect Apple to disclose this amount of time, so developers cannot work around it. The second is to keep a database of developers whom violate the rules, and scrutinize their application updates for what they had previous violated. This means that developers would not be able to break a user’s trust repeating the same action they have in the past.

Ultimately, I think if Apple really wants to have the best experience for users, they should be holding developers accountable for their actions and punishing those developers who violate the rules and provide a significantly negative user experience. One thing that I would not be surprised at is if Mark Zuckerberg gets a phone call from Tim Cook or another Apple executive inquiring as to why this is occurring.

Apps blog

My Coding History: AKA a long way to announce a new version of wwrite

wwrite icon, that's 1024 pixels by 1024 pixels

I’m not the best developer in the world, not by a long shot. I don’t have much formal training. I’ve been doing HTML/CSS coding since around 1997. I took a VB/C++ class in high school, and it was the sole reason I didn’t graduate in January. I didn’t really continue taking programming classes in college, but I didn’t stop programming. In 2001 or so, started working with “classic” Active Server Pages to be able to read Microsoft Access databases, that was around 2002/2003.

In 2004/2005 I changed to PHP to be able to begin customizing a blogging platform to my liking. Which, now that I think about it, it’s been just over nine and a half years since I first started blogging. I’ve been doing PHP/MySQL/HTML/CSS/Javascript ever since. My biggest web-based programming project is actually an inventory/ticketing system for work. That started back in 2007 when we needed a way to keep track of all of our technology. It has grown to include more items than that. Almost every single aspect of the site is custom and works to the needs of my job. Sadly, that’s not my primary responsibility at work, even though it should be.

I say I’m not the best coder for a reason. For instance, it took me over a year to just understand the basic concepts of Objective-C and to begin writing code with it. Most good programmers should be able to pick up the language within a month or so. Having done procedural programming for so long, and limiting my use of object-oriented items, with the inventory/ticketing system, the aspect of sending messages to objects just eluded me. I sat and read books, let those sink in, read some more, and let that sink in, and it finally didn’t really start to click until a year later, around March of 2010.

My first “real” project with Objective-C was the original release of wwrite 1.0.0, I had hoped to keep releasing new versions that kept pace with new features. Sadly, this hasn’t happened. I did start off strong, continually adding versions. Each version added new features, re-worked things a bit, but it didn’t last. I got distracted by other things and easily discouraged when things aren’t working properly; (sadly, that’s a common theme in some, if not most, of my endeavors). The only motivation I had to re-write wwrite was the release of iOS 7 and its complete visual redesign. Instead of just adding updating the app for iOS 7, I opted to do a re-write to make everything easier on myself later on. This culminated in version 2.0.0. The re-working with 2.0.0 made it much easier for 2.1.0. Before we get into wwrite 2.1.0, let’s take a quick look at the history of wwrite.

wwrite’s History

wwrite has been a project I’ve been plugging away at, off and on, for the last four year. It was originally released on April 4th, 2010, one day after the release of the original iPad back on April 3rd, 2010. It would’ve been released on April 3rd, but I wanted to run it on an iPad first, just to make sure everything was working. This was a smart move since some bug was present on the device but not within the simulator. This is why I always test on a device before releasing. Since the initial release I’ve slowly added features. The last release 2.0.0 was back on October 10th, 2013. As mentioned above, version 2.0.0 was a complete re-write that made the code more manageable and would make adding features a lot easier.

The original concept behind wwrite was to make an app that provided a text editor that incorporated templates. Back in 2010 I was still writing my Daily Run Down articles. That was my inspiration for the application. wwrite 2.0.0 was a somewhat ambitious undertaking, particularly when it came to re-writing a significant portion of the codebase. wwrite 2.1.0 was even more so, but more on that in a bit.

In December of 2010 I opted to release an ad-supported version of my app, because I knew some people would not pay $1.99 for a text app. The app is called wwriteFree. Until version 1.6.0, the free version has had feature parity with the paid version. However, with the 2.0.0 version, I never could get the iAd banner to work well with my “Master-Detail” views. wwriteFree still sits at version 1.6.0 until I can figure out the iAd banner issues. Once I do, it will probably be the same feature parity as the latest version of wwrite. I have contemplated on having two different versions of the app, with wwriteFree being slightly behind wwrite, but I haven’t decided if I want to take this approach or not. I’ll have to sit and ruminate on this for a while.

In September of 2010, I decided to release an iPhone Edition of the app, using iOS 4.2. wwrite – iPhone Edition was initially released as version 1.4.0. It had feature parity with wwrite. wwrite – iPhone Edition version 1.6.0 was released on March 23, 2011. Which is where it still stands. To give you some perspective as to how “old” that is. wwrite – iPhone Edition 1.6.0 does not support the iPhone 5, which was released in 2012, nor does it support Retina-level graphics which were released with the iPhone 4 in July of 2011. Just to give some perspective on that.

Ever since I finished and submitted wwrite 2.0.0, there have been certain features I wanted to add. Some of them would be simple to implement, other would be more difficult. The balancing act of ambition versus time, versus ability always comes into play. The balance can sometimes be too much to effectively manage. Sometimes you have a great idea but cannot execute it. Other times you can execute the great idea, but just don’t have the time. It’s all a delicate balance.

A couple weeks ago, sometime around April 15th or so, in anticipation of iOS 8 being unveiled at Apple’s World Wide Developer Conference (WWDC) 2014, I started working on wwrite 2.1.0. wwrite 2.1.0 includes a bunch of new features, all of which are documented here. The biggest features are the ability to archive more than just the files, emailing of archives, and the ability to have more than five templates. All of these were features I had actually been planning on putting in 2.0.0, but just never did, again, due to time constraints.

wwrite 2.1.0

All of that is just a long-winded way of saying that wwrite 2.1.0 is now available. wwrite 2.1.0 is 33% large than wwrite 2.0.0, which I didn’t realize until I submitted the app. It sits at just around 1MB, up from 632K for wwrite 2.0.0. The biggest change to wwrite 2.1.0 is a brand new file format. It now separates the file contents from its meta data. This sounds like a “no duh” item, but it actually took a lot to accomplish.

wwrite has not been a huge money maker for me. I don’t think I will ever recouped my costs of creation. If I were to estimate the total time spent writing code for all three of my apps, I would have to estimate it to around 600 or so hours. Of which, a good 7.5%, or about 45 hours (for those who don’t want to do the calculation), were just in the last couple of weeks to get wwrite 2.1.0 released. It sounds like a lot of time, and it is. When you’re app is only $0.99 or $1.99, it takes a significant number of sales to recuperate your costs. Even at minimum wage, 600 hours would come to approximately $4500. I’m no where near that amount in sales. I’m lucky if I’m even at 10% of that amount, total in four years.

Other thoughts

Regardless of the amount of time, I’m at somewhat of a cross-roads. Do I continue to put forth the effort of adding features to the app when I know I’ll never see a return on the investment. Do I do this just to say I have an app in the app store? I know I’ll continue to have an iOS developer account since I do want to be able to get the latest versions of iOS ahead of public release. But I’m not sure if I’ll continue to update the apps. If I ever do figure out how best to get the iAd banner to work correctly the “Master-Detail” for the wwriteFree, I may release that.

To quote Steve Jobs, “You cannot connect the dots looking forward, you can only connect the dots looking backward”. And I know this is to be true. Maybe all of this work will just be a springboard for me to become a developer full-time at some point. I do not know. Maybe it will ultimately just prove to be an exercise in futility. I know not all developers aspire to have a breakout hit like Angry Birds, Flappy Birds, or any other moderately popular game, but some success is always welcome. Maybe it will come one day, but only time can, and will, tell.

You can download wwrite , wwriteFree, and wwrite – iPhone Edition in the iTunes App Store.

If apps aren’t your thing, I also have some e-books as well. All of their information is located here.