Eric Berna

WWDC 2016 Wishes

Tue, 07 Jun 2016 00:00:00 -0500

Next week Apple will host their yearly Worldwide Developers Conference. Judging from what Apple has done at previous WWDC I’m expecting to see new products, features, and APIs announced on Monday in the Keynote and Platforms State of the Union addresses. The following days will have numerous sessions covering these topics in greater detail.

“If I had asked people what they wanted, they would have said faster horses.”

― Henry Ford

I have no insider information on what will be revealed, but here are my wishes for what Apple announces. I assume the collective intelligence of Apple employees far outpaces my singular brain, so I’ll present my wishes in the form of goals I’m hoping Apple will attempt to achieve, not specific solutions to achieve those goals. I don’t want to be like Henry Ford’s focus groups wishing for a faster horse. I do mention some specific solutions, but these are merely to demonstrate my point. I hope Apple comes up with much better things than I can suggest.

Goal: Encourage Long Term App Improvement

Right now many developers are trying many different ways to monetize their Apps under the rules of the iOS App Store. Few of those ways encourage the developers to release an app, and then follow with an improved version of that app, and then repeat. A few developers seem to be succeeding following this plan, such as the Omni Group.

I want to see Apple change the rules of the App Store to encourage developers to follow this strategy instead of whipping out a quick and dirty app that gets abandoned once the initial rush collapses.

Sure, there will always be plenty of crappy apps that crowd the store, and there will be developers blaming Apple for their inability to make any money in the app store. I’m not asking for solutions to those problems. What I’m asking for is the App Store rules to tilt the playing field towards making great apps that are the result of years of improvements.

Goal: Encourage Cross Platform (within Apple OSes) App Development

All of Apple’s OSes can easily trace their heritage back to NeXTSTEP. Mac OS X is clearly a continuation of what Apple bought when it acquired NeXT. Apple engineers re-thought the user interface layers when they mutated Mac OS X into iOS. tvOS and watchOS are close siblings of iOS. Maybe it’s time to rethink the relationship of all of these OSes to each other, and combine the APIs that are or can be common between them, making it easier for developers for one platform to include the other platforms in their projects.

Goal: Consistent OS Naming

Apple has tvOS, and iOS, and watchOS, and Mac OS X. As I learned on Sesame street, one of these is not like the others.

Goal: Better Games

For a long time now, Apple engineers have consistently produced new libraries and APIs to support better games on iOS. They’ve produced numerous “Kits” (Sprite, Scene, Gameplay, Game, etc.) aimed at game developers. But they are not used that heavily. These kits are competing with game engines like Unity and Unreal.

I’m hoping that Apple does not give up on game technologies. I’m hoping for improvements to all the current Kits and a new Kit or two. I’m hoping Apple does not cede control of game development to the game engines.

Goal: Better Tools

I hope Apple continues to improve Xcode. Specific areas that could use improvement are Swift refactoring tools. Auto Layout tools in Interface Builder could be improved. Also, a minor improvement would be to produce better templates, ones that show different app structures or better practices in coding.

One trend for Xcode I hope they are willing to break is integrating everything. Xcode subsumed Interface Builder. Last year they added a 3D scene editor and animation editors. I’m hoping Apple is willing to break some of these tools out into separate programs so they don’t have to live within the confines of Xcode. I could see them making a companion program for 3D modeling and SceneKit scene design, which could be much better than it fitting inside Xcode.

Goal: An Assistant I Can Use

I work in an open office and live with my wife and kids. Most of the time I’m not willing to talk to Siri. Let me interact with an assistant using text and/or a visual input. Add Siri to Mac OS X as an addition to Spotlight.

While you’re at it, add a Siri API, so I and all those other app developers can add functionality to Siri. Let me tell Siri to add something to OmniFocus, or ask if my Boom Beach base was attacked.

Goal: Better Hardware

WWDC is a developer conference, so I’m not expecting much for hardware. I’d much rather they have so much new software to discuss that they just can’t squeeze in a hardware announcement. Yet, if they do I’m hoping for MacBook Pro, display, and watch hardware improvements.

My work MacBook Pro is almost 4 years old. It’s still a great workhorse, and the new MacBook Pros don’t offer any compelling reason to dump this one for a newer model. Maybe if I could get the iMac’s 5K display in an external package, I’d be interested in that plus maybe a new MacBook Pro if it’s required for running the 5K display.

Apple offers so many watch bands, but each of them only offers two features, a different appearance, and the ability to hold the watch to a wrist. What if the watch bands could add additional features? Maybe add a new sensor, like a blood sugar monitor. Maybe an additional battery.

Predictions

Finally, here are a few minor predictions that I’m not concerned about enough to call a wish:

The code name for this year’s Mac OS will leave the Park. It will not refer to anything in or near Yosemite.
There will not be a broadcasting snafu during the Keynote. This really could go either way, so I flipped a coin to make this prediction.
Apple Pay will add a feature to allow peer-to-peer payments, allowing us to pay from one iPhone to another for things like paying the babysitter.

iPhone SE and 3D Touch

Fri, 04 Mar 2016 00:00:00 -0600

iPhone SE and 3D Touch

As I write this rumors are running rampant about the up coming iPhone SE, a new small iPhone with a 4” screen. Pundits are guessing what features will and won’t be included in the next small iPhone. These pundits seem to have reached consensus that Apple will exclude 3D Touch from this new phone. I disagree.

Supporting 3D Touch requires developers invest extra effort to make their apps respond to the Peek and Pop gestures introduced with 3D Touch. When the hardware and operating system tell an app a 3D Touch action occurs, the app will only respond if the developer wrote appropriate code.

From a developer perspective I like supporting new technologies like 3D Touch. From a business perspective I like engaging in profitable activities. Sometimes there is a conflict between these two perspectives. From the business perspective I like investment in supporting new phone features, because I think I’ll delight my customers which should lead to profits. A new technology like 3D Touch can’t be in all phones, because it requires new hardware, but I expect this technology to eventually be in all phones Apple sells. Yet if Apple signals that a technology will not eventually be in all their products, they are telling me that effort towards supporting that technology will only potentially please a subset of my customers. Being able to please only a subset of my customers pushes the priority of supporting a phone feature further down my list of improvements to make to my apps.

By failing to include 3D Touch in any new iPhone Apple signals that 3D Touch is not a feature they plan on supporting in all their phones. I then will have greater difficulty supporting the technology from the business perspective. Making this a feature in only part of their phone product line means that I as a developer need to write code that gives full utility of my apps without 3D Touch. This means the full utility will be in my apps even on phones that have 3D Touch. So why expend the effort to support 3D Touch?

Apple wants 3D Touch to succeed. Apple is full of smart enough people to think through this line of thought. Apple sees that the cost of not including 3D Touch is much higher overall than skipping it on this one model.

We’ll know in a few weeks, and I’ll post an update once I’m proven right or wrong.

Update

Well, I was wrong. The iPhone SE does not include 3D Touch. Yet the iPhone SE is outselling Apple’s expectations. Now it’s a longer waiting game. Let’s see what happens at WWDC 2017, and how much Apple talks about 3D Touch. I’ll check back again later and see if 3D Touch is thriving.

Mistake: Having a Developer of Native iOS Apps Write Native Android Apps

Tue, 29 Dec 2015 00:00:00 -0600

Mistake: Having a Developer of Native iOS Apps Write Native Android Apps

Of course the reverse is also a mistake; having an expert at developing native Android apps write native iOS apps. The best one platform native app developers are very slow and produce bad products when writing native apps on a similar platform. Without focus, mediocre dual platform native developers only slowly become better when they are writing for both platforms.

The native SDKs for iOS and Android are huge collections of software each designed to solve the same problem, support the running of native code on a mobile device. A person must learn a huge amount of information to become a good native developer on either platform. The body of knowledge a good developer of native apps needs to know keeps expanding as Apple and Google continue to develop their respective mobile OS. A developer switching to the other platform needs months, maybe years, to learn that other platform. This developer needs to unlearn the philosophies, patterns, and techniques unique to the first platform while learning the different knowledge of the second platform.

Switching focus and taking the time to learn another other platform is necessary and important to software developers careers. It happens all the time as we developers stop working on one platform and retrain for the new platform. The real mistake is expecting a developer to continue to write code in their first platform while writing code on the second platform. What most often happens is the developer keeps the first platform knowledge and merely translates what he must to the new platform. Such a developer will write a program for his first platform on the second platform, which can cause a number of quality defects in the final product. The final product can seem out of place to the users, since it may follow the conventions of the other platform. The final product can be buggy, slow, and inefficient, as the best way to programmatically accomplish any individual task on one platform may be the worst way to accomplish the same task on the other platform.

Even worse is when those in charge assume that a mobile developer is a commodity, and can be easily reassigned to work on a different platform. If little accommodation is made for the developer to retrain for the other platform the developer ends up only learning the very specific aspects of the new platform that matter for that project.

An Old Mistake

This mistake has be around for almost as long as companies have sold software packages. I remember seeing companies make this mistake way back in the 1980s, when Mac developers were writing early Windows apps the Macintosh Way. Or even worse, when DOS developers tried to write Mac or Windows apps the command line way.

Needed: A Bigger Difference

Developers should work on more than one platform, but the problems each platform attempts to solve should be very different. The iOS and Android SDKs both try to solve the problem of writing general programs for mobile devices. A platform designed to solve a different problem like making games, websites, or desktop apps, has enough differences to avoid the issues with similar platforms.

I highly encourage all developers to expand their abilities by working on more than one platform, as long as that platform is significantly different from your primary platform. I’m a developer of native iOS apps, and I’ve recently chosen to work with Unity, a web framework, and even Arduino. All of these are significantly different from iOS native development. With little overlap, I can learn these other platforms without conflict with my primary platform.

If You Must

I recommend, if you must do cross platform mobile development on iOS and Android, to use a tool that can compile to both platforms. Use a game engine like Unity for a game. Use Xamarin. Build a Cordova app with HTML5 technologies.

Another alternative is to hire another developer to work on the other platform. A contract programming firm should have at least two specialists on a cross platform native app project. A product company should do one platform first, and when the product grows to the point it can support and benefit from the app on the other platform, hire another employee or the necessary contract programmers to write the native port to the other platform. Hire specialists on the other platform.

Or convert one or more of your first platform specialists to the second platform. Let them know this assignment is permanent (as permanent as any job assignment can be today). Just make sure to give them the time and understanding it takes to switch.

One Weird Trick for SysOps Mastery

Thu, 02 Apr 2015 00:00:00 -0500

One Weird Trick for SysOps Mastery

I recently setup a Gogs server. This post is not about Gogs, but the process I used to set up Gogs so it was just right for our needs.

Gogs is a git service. We’ve been using gitolite for a few years now, but our business needs have grown and we need a web interface to our git server. So we’re giving Gogs a try.

Gogs is relatively new software that has numerous configuration options, and external dependencies. Each installation will differ based on available resources and workflow needs. Figuring out our setup was a process of trial and error. More than once I realized I made a bad choice at one point or another, and decided to start over.

The trick I used to make this process go faster and prevent making the same mistake more than once was to write a detailed installation guide covering every step of the process.

Some of the steps were the exact bash command as entered into Terminal. Some of the steps, such as install Virtual Box, were much broader. I documented what I needed so that I could exactly duplicate my process if I needed to do it all over again.

When I realized it just wasn’t working with CentOS, and decided to switch to Ubuntu, I did not completely start over. I changed only the instructions that were effected by the switch in OS, and then followed my instructions. Most of the other decisions were just fine at this point, and I didn’t have to think about those choices making this round go so much faster.

The most important part of this process was to document each step before taking that step. I figured out what I needed to do next, and wrote it down. Some times that next step may have been fixing an error I made earlier, going back to that step, and proceeding through the instructions.

I won’t share my instructions, because they probably won’t work for you. You need to think through all those decisions in your situation, not blindly follow my decisions.

The only instruction I will share is to document your own process as you figure it out.

Testing with KIF

Thu, 02 Apr 2015 00:00:00 -0500

How Could I Miss This?

I’ve been professionally building iOS apps for many years. All that time I’ve known about automated tests. I’ve written many unit tests that cover computations and data manipulations in my code. Yet I’ve struggled with testing iOS apps.

I work for a design firm, so when our customers have projects where presentation is their primary concern they think of us. Most of the apps I work on are more about the presentation than the collection or manipulation of information. Testing the user interface of iOS apps using Apple’s tools included with Xcode is very difficult. So I generally didn’t write automated tests for much of our code.

Last week I heard about KIF, a iOS testing framework. Today I got a chance to play with the testing framework. I went through the Ray Wenderlich tutorial on KIF. Where has this been? Why did I miss this? It makes automated UI testing of iOS apps a breeze. KIF is built on XCTest, so writing and running tests is just like running XCTests.

The Ray Wenderlich tutorial is a year old, and a bit out of date. If you try it, download the example code, delete the Cocoapods artifacts (the workspace, the pods folder, and the podfile). Then follow the instructions from the KIF readme file for installing KIF through Cocoapods. Then the tutorial mostly just works.

Fun with SCNShadable

Fri, 20 Mar 2015 00:00:00 -0500

Apple’s Scene Kit framework is a little under documented. I’ve been working with it trying to make a special effect by modifying the built in shaders for Scene Kit objects. Here are a few things I found out.

Scene Kit includes a SCNShadable protocol that defines the way to modify geometry and material objects with OpenGL Shading Language (GLSL) programs. One option is to totally replace the vertex and fragment shaders with an SCNProgram module. The other option is to insert snippets of code at specific points in the built in vertex and fragment shaders with shader modifiers.

I was having some difficulty understanding exactly what I could and could not do in these code snippets. I wanted to see the entire shader program, but I could not find these shaders in the documentation. I hope the reason Apple’s engineers have not documented this code is to leave themselves the option of changing it in the future. Fortunately Xcode is more than happy to show you this code; all you have to do is make a syntax error in your snippet. When the app fails to compile the shader it spews out the entire shader program to Xcode’s debug area console pane.

There are multiple versions of these shaders, depending upon how you setup a geometry or material. For example, changing the lighting mode for a material changes the lighting section of the fragment shader.

There are four named and fairly well documented insertion points for the shader snippets. These insertion points are within the shaders’ main() functions. Additionally, each snippet is analyzed for the existence of structures that should be inserted before the main() function definition. Apple documents how you can use the #pragma body directive to make your own function definitions. It also moves any uniform definitions to the declaration portion of the shader.

One of the four named insertion points, SCNShaderModifierEntryPointGeometry, results in code inserted into the vertex shader. The other three result in code inserted into the fragment shader. This means you can insert modifiers into both parts of the shader program.

For my project, I needed to pass some values from the vertex shader to the fragment shader. Apple’s documentation doesn’t mention using varying values, but after figuring out the above processing of shader modifiers I decided to just try adding them to the geometry and fragment entry points. It compiled and ran, and with some tests I made sure the varying values worked.

Switching to Jekyll

Thu, 19 Mar 2015 04:19:34 -0500

Today I learned that I just don’t have the time to maintain WordPress sites. If I don’t log in and update the site frequently enough I just end up with a broken or hacked website. I’m abandoning WordPress and switching this website to Jekyll.

I’m rebuilding this site. At first I’m posting the bare minimum so I can shut down the WordPress site. As I can I’ll update and restore the old material, improve the theme, and post new content.

Learning Modern 3D Graphics on iOS

Thu, 19 Mar 2015 00:00:00 -0500

Modern 3D graphics APIs such as recent versions of OpenGL use a programmable rendering pipeline. I first learned about the older fixed-function rendering pipeline. I took a course in college on 3D graphics programming that taught lots of theory and an older version of OpenGL. I’ve produced programs that portably run in GLUT on both Macs and Windows. I’ve written an iOS app that uses OpenGL ES 1. Yet I was slow to make the jump to the programmable pipeline versions of OpenGL.

One day I came across Jason L. McKesson’s online book Learning Modern 3D Graphics Programming. After a quick perusal I concluded the book could be a refresher for 3D graphics programming while moving me up to the programmable pipeline. I started reading the book, downloaded the source code, and tried to get it running on my Mac.

I didn’t have much luck. The framework McKesson wrote to isolate his example code from the overhead of displaying a window on screen and interfacing with the operating system seems to be written for Windows first, then ported to Unix like systems (Linux, etc.). It doesn’t “just work” in Xcode on my Mac. I soon found that building McKesson’s framework in Xcode would be a significant effort.

I’m an iOS developer. I want to write OpenGL ES 2 code in iOS apps. Apple’s GLKit in the iOS 5 API serves the same function as McKesson’s framework. I realized any effort put into getting McKesson’s framework to build in Xcode on my Mac would not actually serve my final purpose. Instead I should just use the source code of McKesson’s tutorial programs as guidelines for building iOS apps. For each of McKesson’s example programs I’ll write the equivalent GLKit iOS program.

When I started this project McKesson’s book was a work in progress. Now, a few years later, McKesson appears to have abandoned his project, as the book is no longer on line. As far as I can tell the project was never completed.

When I wrote my example programes I decided to share my efforts. As I made my way through the tutorials in this book I wrote up a description of how my programs differ from the originals. My blog posts built on McKesson’s book, covering merely the differences between his example programs and my iOS versions. I published my work to Bitbucket.

I came back to the project today, thinking I’d give it a little love, updating the projects for iOS 8, maybe even porting them to Metal as practice. Yet, my willingness to give this project any more effort evaporated when I saw that McKesson hasn’t progressed the book in years. I’ve removed my project from Bitbucket.

Instead I think I’ve found something more interesting, The Book of Shaders by by Patricio Gonzalez Vivo. Maybe I’ll make iOS example programs from that book using Metal.

It's a Race

Thu, 28 Jun 2012 00:00:00 -0500

Who’s faster at shipping to me from China? FedEx or UPS?

I ordered two products from Apple on one order. Both were made in China, and shipped straight to me from the manufacturer. UPS was tasked with delivering the product made in Shanghai, and FedEx was tasked with delivering the product made in Chengdu. Apple sent me two shipment notification emails, one for each product. According to the email headers, UPS got the package at 10:35 pm my time, and FedEx got the package at 10:45 pm my time.

I chose the standard free shipping. My guess is that Apple chose to use UPS and FedEx because they were the cheapest supplier at each location. FedEx calls their service International Economy Distribution, and UPS calls their service World Wide Express, making the UPS service sound faster, but why would Apple pay extra for a higher level of service?

Since UPS got an 10 minute and almost 2,000 mile head start we’ll spot FedEx a day in the race. I’ll call it a tie if the FedEx package gets to me the next business day, and give FedEx the win if both packages arrive on the same day.

The race started on a Wednesday (Thursday in China). The race will span at least one weekend, and probably the Fourth of July holiday. I’ll only count my business days.

Update 1

UPS took an early lead. While FedEx said the package got to them after their local cutoff in China, UPS got the package at the same time and got it moving. China has one timezone, so they got the packages at the same time on the clock, but the sun sets about two hours later where FedEx picked up their package. So FedEx is far behind after the first lap.

Update 2

Twenty two hours after the initial shipment notification emails FedEx reports that the package is sitting at their location in Chengddu. UPS is reporting that they are having mechanical difficulties with their airplane, which should be an excuse for slowing them down. Yet, they’ve gotten the package to Anchorage, AK. Looks like UPS is expanding their lead.

The Results

I got both packages the same day. UPS actually got the package to my office door on Saturday, but nobody was here, so they had to come back on Monday. The day the packages arrived FedEx was a few hours later in the day, but, as I said above, FedEx was spotted a day for having to travel further. So for speed, I have to award a tie.

Considering service, style, and overall quality of the experience, UPS did a better job. The UPS website was updated in real time. As far as I could tell events scanned in on the package are communicated back to the home office and posted to the website immediately. Each event that happened appeared on the website as it happened. FedEx batched updates to the website. There would be no updates for a extended period of time, then suddenly a bunch of updates would appear. The website would report that the package was received at a location, processed, and departed the location over a few hours. During that time I did check the website, but didn’t find any updates. Then hours later the updates would appear. For example the package was on the truck for delivery before I woke, but when I checked on the race the website reported it was still in Tennessee. Four hours later the website reported that the package left Tennessee, arrived in Milwaukee, got processed, and was placed on the delivery truck.

FedEx also made a mistake. I work in an office building with a number of different companies. My office is on the second floor. The delivery label clearly said “Second Floor”. Yet the FedEx package was dropped off with a company in the basement.

Goodbye World

Fri, 14 Oct 2011 00:00:00 -0500

#include <stdio.h>
int main () {
    printf("Goodby Dennis Ritchie.");
    return -1;
}