Category: iOS
You are viewing all posts from this category, beginning with the most recent.
Apple's Native Apps Trojan Horse
Apple announced SwiftUI at WWDC 2019 and like a lot of people, I mostly ignored it because I knew that it would need some time to mature before it would be ready to use in production software. I also wasn't sure if it would "stick" in terms of long term, viability. However, after another year of development, it's clear that Apple has made a commitment to it. The newly announced Widgets and App Clips as well as enhancements to WatchOS definitely push developers hard towards SwiftUI.
SwiftUI appears to be Apple's answer to the React programming movement, and given the similarity of SwiftUI to React, I expect a lot of the response will be positive. However, I believe this to be a bit of a Trojan Horse in relation to cross-platform development. As I mentioned earlier, apps that want to use some of the newer technologies, like Widgets, have no choice but to use SwiftUI. For an app that's written natively in Swift, this will be easy. Apps written in cross-platform environments will have to work a lot harder.
Eventually, Widgets and App Clips will become expected functionality for many apps, and while most cross-platform solutions already support mixing native code with non-native code, the level of complexity of supporting these will essentially require developers to be fluent in multiple languages and multiple development environments. I'm very curious to see how these cross-platform development communities respond and adapt to this change because over time this will erode one of their key advantages.
Finishing Software Is Hard
For the last couple years, my 15 year old son has been slowly building a gaming computer for himself, piece by piece. For his final computer component, I agreed to purchase it for him if he could accomplish one very specific task. Namely, I wanted him to recreate an iOS app that I had written years ago as I was learning iOS development. He has a natural inclination to programming and has dabbled with many different coding challenges so he figured that it wouldn’t be too difficult to do.
For the most part he was correct. He started working on it last summer and was able to quickly get a large chunk of the functionality working. He was fairly excited about it, but then I started explaining some of the other things he needed to do before submitting it: an about screen, a splash screen, cleaning up the layout for the various phone screen sizes, etc. What happened next was predictable. His enthusiasm waned and he pretty much stopped working on it. He filled his time with other things and his almost-finished computer sat staring at him in his room.
On more than a few occasions he tried to negotiate a smaller task, but I kept explaining to him that the point of the exercise wasn’t to see if he could program (I knew he could.) But rather, could he finish something hard and complex. As any seasoned developer knows, finishing software is difficult and always takes longer than you expect. It’s also not a skill that people learn in school. It’s something that can only come with time and experience.
During this period of extreme social distancing, our kids haven’t had school and the transition was so sudden that teachers didn’t have time to create assignments or lesson plans for students while they are out. As a result, our kids find themselves on some bizarro extended spring break where they can’t see anyone. The boredom is real and families are trying to figure out what to do with themselves. The silver-lining for me is that I have a little more time to spend with my family and I finally convinced my son to sit down and finish his app.
The amazing thing is that as soon as he finished and submitted to the App Store, he found a sort of “second wind” where he wants to keep working on the app and add more features and functionality. To me, this is the magical reward of finishing software. When you finish something you feel such a sense of accomplishment and get a boost of energy and enthusiasm. It’s a feeling that I love and is difficult to explain to someone that hasn’t gone through a tough finishing exercise. I’m very happy that I was able to share this with my son.
Oh, and if you’re curious about the app he built, you can find it here:
https://apps.apple.com/us/app/doodle-dots/id324487932?ls=1
Tools for a Distributed Software Agency
One of the things that I am most proud of is that Silverpine is a 100% distributed company. Often when people find out that we are fully remote, they will ask curiously about what tools we use to work together. This is completely understandable because the importance of having the right tool set is magnified for remote companies. We understand this innately and as such we are constantly evaluating our software stack. The following list represents the software that powers our business. (I have intentionally omitted some of the lower level development tools like Xcode and Android Studio.) The list is broken into four primary classifications: communication, development, project execution, and finance.
Communication
Slack
Before Slack, we used a hodge lodge of messaging tools like AIM, Google Chat and even old school SMS. It was horrible. Slack is the single most important tool that we use to communicate with each other and with our clients. All of our employees and contractors use it extensively every day, and even though I think that there should be some middle ground in their pricing between the paid and the pro plans, I can't imagine trying to work remotely without it.Webex
Let me just preface this by clarifying that I think that every single conference calling platform is terrible. I have used them all. From Zoom.io to Google Hangouts to AT&T Connect, they are just barely workable. Besides the all too common call drops they also all seem to suffer from ridiculous installation processes and byzantine user interfaces (Does this yellow button state mean my microphone is on mute or can they hear me?)That being said, we have been using Webex for a very long time; not because it is good, but because it is better than the alternatives. And for our enterprise clients, it is somewhat of a known entity so we seem to spend less time per call doing the “can you hear me” dance. I wouldn’t say that I recommend Webex. It’s just what we use.
Dropbox Pro
We have been using Dropbox on personal plans for quite a while, but we recently decided to standardize on Dropbox Pro for file sharing. All of our projects have quite a bit of documentation, graphical assets and other large files that aren't well suited for source control tools. Dropbox allows us to create per project file drops that we can easily access as well as share with other people when appropriate. We almost switched to Box.com because their pro plans have unlimited storage but ultimately decided it would be less transitional headache to just upgrade our existing Dropbox plans.G Suite
We have been using Google for our email and calendar services for so long that our silverpinesoftware.com domain is still functioning under the original beta operating agreement. If G Suite disappeared I honestly wouldn't even know where to start looking for a replacement. File this one under "it just works."Development
InVision
One of Silverpine's guiding design principles is that every user interface needs to have a beautiful "feel" to it, and that you simply can't judge the feel of an app until you can hold it in your hand and interact with it. Because of this philosophy, we have refined our development process over time to rely heavily on InVision to prototype the UI and UX of our apps before we ever even start writing code. The amount of time and pain it saves both us and our clients cannot be overstated. If you design for mobile, you really should be using InVision or something like it.GitHub
If you write software, you should be using a source control platform. If you need a source control platform you should be using GitHub. If you're using something else, I'm sure you have a reason for it, but it's probably not a very good reason. (All of our projects use GitHub repositories so when they changed their pricing model to be per user rather than per repository, it made our lives a lot easer.)Azure DevOps
This one might surprise some people, but a couple years ago we transitioned to what is now known as Microsoft Azure DevOps for our automated build system and have been using it ever since. Prior to Azure DevOps we had used a variety of tools including TestFlight (bought by Apple), Fabric (bought by Twitter, then bought by Google), and BuddyBuild (ran out of money). Due to intense consolidation in that particular sector, we were frequently having to retroactively change our toolset which was both time consuming and costly. A friend of mine who works on the Microsoft tools team encouraged us to give Azure DevOps a try, and we have been extremely happy with that decision. Azure DevOps supports both iOS and Android, is massively configurable, has 24/7 support and most importantly, is backed by one of the largest companies in the world so it won't be disappearing any time soon. If you need an automated build system and haven't taken a look at Azure, I highly recommend at least kicking its tires.Project Execution
Basecamp
For many years, we wandered in the desert of project management, largely piggybacking on whatever project management tools our clients happened to be using at the time. As such, we have used everything from Jira to Asana to Microsoft Excel to track projects and tasks. However, in the past year we have implemented Basecamp as our standard internal project tracking tool. One of the things I like best about Basecamp is that it has clearly been thoughtfully designed. Not only is it powerful, but its design somehow works to ensure that it doesn't become overly burdensome in the same way that other similarly complex tools do.Lighthouse
If there was one piece of web software that I would invest internal Silverpine resources on, it would be a lightweight bug tracking tool. There just aren't many platforms out there that can strike a balance of utility and ease of use that errs on the side of ease of use. For now, Lighthouse foots the bill for us in that regard, however, I'm not sure how much longer it will be around. There hasn't been any significant development done on it in the 6+ years that we've been using it, so I'm not sure I would necessarily recommend it. That being said, it does what we need bug tracking software to do, and it does it well, and I haven't found a replacement. If you have any personal favorites, please let me know.Finance
Blinksale
Silverpine is a services business and sending invoices to our customers is literally how we are able to make money. Blinksale is the tool we use to send those invoices and look like we are professionals in the process. While it isn't a complex tool, it expertly does what we need it to do: send and track professional looking invoices. If you send invoices to clients, you really should be using a tool like Blinksale because people can tell when you don't.Quickbooks
Nobody really loves Intuit. They have created not one, but two near monopolies with TurboTax and Quickbooks. However, if you run a business, you need to track your finances in a way that your CPA can help you with your taxes at the end of the year, and if you tell your CPA that you use anything other than Quickbooks, they will not be happy with you and they will very likely take longer to do your taxes which means you will end up with a higher bill from them. That is the reality of Quickbooks and that is why we use it.Gusto
If you have employees or sub-contractors that you need to pay, you really should be using Gusto. The folks at Gusto are wizards when it comes to dealing with payroll taxes and W-9's and a great deal more things that I simply don't have to worry about because we use their service. Not only is the Gusto platform super easy to use, but their customer service team is actually pro-active in notifying us of upcoming tax law changes that might affect us. I am continually in awe of how great Gusto is and cannot say enough good things about them.
Thanks for the Memory
How much memory can an app allocate on an iPad 1? It seems like a trivial question. The original iPad has been in circulation for over 3 years now and developers have written thousands of apps, many of which are memory intensive. Given this, one would expect that this limit has been well documented and should show up easily in search results. As I found out recently, this is not the case.
A few weeks ago, I needed to revisit memory consumption on an app running on an iPad 1, and I became very curious about the answer to this question. After searching various sites I was mostly coming up empty. To my surprise, it was quite difficult to find this documented anywhere. Apple's own documentation is of course great reading for any developer but remains mum on memory budgets. Perhaps the best documentation I could find was this Stack Overflow post, but it didn't seem to be definitive and as with all Stack Overflow posts, caveat emptor.
One thing that I did find sprinkled around the various posts on the topic was a link to Jan Ilavsky's tool that he wrote to measure on a device the various points when an app receives memory warnings and then ultimately crashes due to insufficient memory. Here's a shot of it in action. Using Jan's tool, I decided that perhaps I should help contribute to the collective information of the Internet by running some tests and documenting them.
So as not to boil the ocean, I decided to analyze only the iPad family of devices. My test devices included: a first generation iPad, a second generation iPad, a third generation iPad and an iPad Mini. All of the devices were upgraded to the latest version of iOS that supported them*. My procedure was to force quit all apps on the device before running the test app and then to run the test a minimum of 10 times on each device. I would then throw out the low and the high and graph the results. I found to be both interesting and somewhat predictable:
[caption id="attachment_58" align="aligncenter" width="300"]
First Generation iPad (iOS 5.1.1) [/caption][caption id="attachment_59" align="aligncenter" width="300"]
Second Generation iPad (iOS 6.1.3)[/caption][caption id="attachment_93" align="aligncenter" width="300"]
iPad 3 (iOS 6.1.3) [/caption][caption id="attachment_61" align="aligncenter" width="300"]
iPad Mini (iOS 6.1.3)[/caption]One of the more interesting things that jumped out at me is the fact that Apple seems to take memory optimization seriously, and that their approach appears to not be a one size fits all method for the different devices. Notice how on the second generation iPad and the iPad Mini the OS continues to optimize in order to allow the app more room in which to operate. Contrast that with the first and third generation iPads which appears to have a flat, non optimizing algorithm. If indeed memory optimization does have a certain amount of device specificity to it, it would appear that Apple put less time into optimizing these iPads.
This of course makes sense as the first iPad was a previously non-existant category, and the third generation was the first iPad with retina display. You have to imagine that it was a pretty massive undertaking to introduce the retina concept on an OS, toolchain and device level. I don't think any engineer alive would be surprised if the schedule became tight on these projects. The point here however, is that Apple does indeed pay attention to the details and that permeates all the way down to device specific memory optimizations. Developers should of course never become reliant on the presence of these optimizing algorithms but the fact that Apple puts that much attention into it is impressive.
So, back to my original question of how much memory you can allocate on an iPad 1. Drumroll please. Based on my results, I would say that for the iPad family of devices the following are the maximum allocations that can be performed by an app:
First Generation iPad: 160 MB
Second Generation iPad: 250 MB**
Third Generation iPad: 515 MB
iPad Mini: 275 MB***
Now, I wouldn't be doing my civic duty if I didn't point out that these numbers include things that are entirely out of your control such as core graphics objects. The test application is the most plain vanilla of apps so the minute you start making anything interesting this number will begin to be impacted. In the end, there is simply no replacement for good old fashioned testing and optimizing so keep that in mind as you're setting out to make the next Angry Birds. I do find this helpful however because it is useful to know and be aware of what my overall ceiling is so that I can spend time optimizing the things that need optimizing and spend the rest of the time building features.