Personal Capital recently updated its iPhone/iPad application to include a new 401k fund fee feature as well as add support for iOS 6 and iPhone 5. Adding support for a new OS as well as a new device, especially one with a new screen size, is always a great test to a project’s architecture and code. A properly architected project allows the developer to add support for new features with minimal adjustments to the project.
The Personal Capital iPhone/iPad project is a testament to the value of not using WYSIWYG tools. The application supports a range of operating systems as far back as 4.3, and takes advantage of each device’s retina display if available. Every screen is created purely from code and takes advantage of Apple’s APIs that allow a view to re-size and/or adjust the position and functionality of objects based on the current screen size and device rotation. Based on this architecture, updating the project to support iOS 6 and iPhone 5′s 4-inch display only required a few changes.
WYSIWYG tools are SDK dependent. This means that when a new feature is introduced, there will need to be an update to the SDK and accompanying WYSIWYG tool to support these features. Since these features did not exist in the previous WYSIWYG, you will need to update each of the corresponding WYSIWYG files associated with the tool to correctly utilize these features. For example, the latest version of XCode’s Interface Builder allows support for the iPhone 5’s new 4-inch retina display by providing an additional “Size” property for views. If your application uses Interface Builder to create its screens, you will need to update each of your nib files if you want your application’s views to re-size correctly. If your project was built without Interface Builder and is coded for a dynamic screen size by utilizing the frame and bound properties of a view, you don’t need to do anything to your code to support additional screen sizes and layouts.
When a new OS rolls out, there are exciting new features to take advantage of as well as deprecated methods. If your project is fully code-based, you can do a simple word search to find the points in your code that you want to update. WYSIWYG tools are unique to each SDK but most are not easily searchable since they are designed to be visual tools. If the WYSIWYG files aren’t binary, you can do a word search on them but most likely the keywords you need to search upon are specific to the tool and will be different than the property or method name associated with the class’s code-based counterpart. This means even if you can search upon a WYSIWYG file, your efforts are doubled.
This brings me to the concept of developing for multiple clients. Successful applications will eventually port to multiple clients and the need to not have to “reinvent the wheel” for each client is essential. If you are building an application that doesn’t need to utilize UI elements specific to a platform, you can develop your entire application in C so it compiles for iPhone/iPad devices and also support Android devices using the Android NDK. Obviously, this approach is great for code-reuse but doesn’t allow you to utilize some platform specific features that are accessed via platform specific classes. I’d love to build an application completely in C so that the code is shared across platforms, but this way can be a little masochistic if you actually want to incorporate platform specific elements into your application.
So what options are left? If the exact code can’t be reused across clients, you can still reuse the logic. The Personal Capital application features a variety of dynamic and interactive visual elements that are all built using custom code. Since they are built entirely in Objective-C without the use of a WYSIWYG, I was able to take the exact code and “Javacize” it for the Android platform. This meant literally taking the code and just changing it to Java but leaving the logic. I had not looked at parts of the code in months, so some of it was a little foreign to me. Since I was simply converting Objective-C to Java, though, it didn’t matter. This means sections of an application that had been complicated to create on one platform can be delegated to anyone who knows both Objective-C and Java even if they aren’t familiar with the code.
Reusing code in this manner also facilitates the QA process of application development. Since the same logic is used on all platforms, your QA department doesn’t have to deal with testing a completely new product. Any issues that arise can be fixed by resolving the issue on one client and then quickly mapped to the other clients.
If portions of your application are created with platform specific WYSIWYG tools, though, this process begins to fall apart. Besides being platform specific, WYSIWYG tools create a black-box effect on a project. Most tools do not go into depth the one-to-one relationship between what is being achieved and how to accomplish it in code. If a developer is familiar with the platform API and its classes, the process becomes mappable, but at this level of understanding, most developers opt out of using a WYSIWYG for actual code since it’s more dynamic and customizable.
There are cross-platform WYSIWYG tools, most of which are HTML5 based. Many of the simpler applications that you see in the market place actually could have been built using these tools which would have saved the developer the hassle of managing multiple code-bases. But the key word is simple. HTML5 applications will never perform as well as a native application and can’t integrate platform specific functionality at the level that a native application can.
There is nothing wrong with using a WYSIWYG if you’re new to a development environment and need to get up and running quickly. But if your developing complex, dynamic applications that extend beyond out-of-the-box platform elements, you will find that most of your work will be done in code and you’ll most likely drop the use of any WYSIWYG implementation to maintain a clean code-base that can be ported to different platforms.