Apple has announced a major initiative related to developers, and specifically for an under represented group of developers. When you look at the overall genetic makeup of developers, you may have noticed that there is a disproportionate number of males as developers, as compared to women. Apple has begun an initiative to help correct this imbalance. They call it their Entrepreneur Camp. The Apple Entrepreneur Camp is designed for organizations that are founded and led by women.

There will be four two-week camps run over the course of the next year, these will take place during one of these times:

January 28–February 8, 2019 April 1–12, 2019 July 22–August 2, 2019 October 14–25, 2019

There are some requirements before applying. These requirements are:

• The organization must have a woman founder, co-founder, or CEO;
• The organization must have a woman developer proficient in Swift or Objective-C
• The organization must have a developed app or functional build created for any platform that you can demo live.

Additionally, the applicant must have the following requirements:

• You must be 18 years of age or older and proficient in English.
• The woman founder, co-founder, or CEO, the woman developer, and another employee (if applicable) must be 18 years of age or older, proficient in English, and able to attend together for the entire two-week lab.
• Attendees must be able to bring their own laptop to work on their code in the lab. After you have applied, and if you are accepted, you will be in a two-week lab.
• If you are a woman who has founded you can learn about all of the details at Apple's Entrepreneur Camp website.

Per Apple's site,

Apple Entrepreneur Camp consists of an immersive technology lab, as well as mentorship, education, and support. Selected organizations receive:

• One-on-one code-level guidance from Apple engineers at a two-week technology lab in Cupertino, California. Ongoing support from an Apple Developer representative for at least one year.
• One year of membership in the Apple Developer Program.
• Up to two tickets to WWDC for the woman* founder, co-founder, or CEO and woman developer.
• Access to the Apple Entrepreneur Camp alumni network, a world-class group of inspiring and ambitious senior women leaders.

If you are a woman, or part of a woman-led development company, it would behove you to apply for the Entrepreneur Camp. It is great to see Apple putting so much time and effort into help woman-led companies with mentoring as well as tickets to the next World Wide Developer's Conference.

You can read all about the camp at Apple's Entrepreneur Camp website. Applications are open now.

Fifth in my look at the iPhone X we will tackle an area which will not be prudent to everyone, but may be of some interest to many. That topic is what developers need to look at when it comes to their applications on iPhone X.

The iPhone X represents a number of changes, an OLED screen with High Dynamic Range (HDR) support, improved camera, significantly improved processor, and Face ID, just to name a few. Many of these new features require some thought from developers to be able to have the best iPhone X experience for your users. If you have been keeping your application up to date, there may only be a few tweaks that need to be done to fully accommodate the iPhone X. Let us start with items revolving around the screen.

Screen

The iPhone X has an all new 5.8 Super Retina HD screen. This screen is an OLED based screen with a resolution of 2436 pixels tall by 1125 wide with 458 pixels per inch. This means that it has a true 3x screen due to the width being 375 points, and the height being 812 points.

This 3x screen means that developers may need to provide assets at true 3x resolution. It was possible to provide almost 3x resolution assets before since the Plus-sized iPhones were scale down any 3x resolution assets to appropriately fit the screen.

It is not likely that many developers would have not had true 3x resolution assets, but in case you did not, it is important to do so now. Along with this, the iPhone X is its own distinct screen size. Throughout the iPhone's history there have been a total of six different screen resolutions. These have been:

• 320 pixels by 480 pixels
• 640 pixels by 960 pixels
• 640 pixels by 1136 pixels
• 750 pixels by 1334 pixels
• 1080 pixels by 1920 pixels
• 1136 pixels by 2436 pixels

If you are planning on supporting all of the currently supported devices, you will need to support the last four screen resolutions. Since the iPhone X is quite a bit taller, 216 pixels to be exact, you will need to make sure that your assets support the proper aspect ratios in order to be sure that everything appears correctly on each different iPhone model. There is one thing somewhat related to the screen.

Dark Modes

Each user of any application is unique. While you will never be able to please everyone, there is something that you can do to help a segment of your user base. Some users enjoy customizing the way that things look and for some of these users prefer a darker screen. This could be due to eye issues, or just because these themes are more visually appealing to them. For whatever the reason, it may help expand your user base to include a darker theme. The iPhone X may just give you the impetus to creating one within your application.

With the iPhone X being OLED, burn-in may become an issue over time. Even though Apple has done many things to help minimize burn-in, there is one thing that app developers can do to help; implement a dark mode within your app. With OLED, pixels are only turned on when the color is anything other than black. This means that if your application has a dark mode built-in you can help save a user's screen. Another side benefit of this is that you can also help save battery life for users since the iPhone X will not need to turn on the super dark pixels. If you do not have a dark mode, it may be a good time to start implementing one, you never know it may just help expand your user base.

Face ID

Starting with the iPhone 5s, Apple has included a biiometric authentication mechanism with Touch ID. Touch ID has allowed for convenience when needing to unlock your iOS device or enter in a password. In order for developers to access the Touch ID sensor, Apple created the LocalAuthentication Framework.

The LocalAuthentication Framework provides two return values, a Boolean for the success or failure, and an NSError object, so you can determine the actual error that has occurred. That is all that you, as the developer receive. Given that the LocalAuthentication framework handles the actual authentication and determines which authentication mechanism to use, there is not much that a developer has to do.

The approach of only providing a success or failure, as well as an error, makes the LocalAuthentication framework infinitely scalable, from a developer's point of view, and reduces the need for complex code. Ultimately what this means for developers is that they have minimal work to do to support Face ID on the iPhone X. In fact the only work that needs to be done is updating strings to refer to Face ID instead of Touch ID, when on an iPhone X. There are no other code changes necessary in order to support Face ID. If a developer does not have time to update their application right away, their application should continue to work, just with the wrong text showing on the iPhone X.

The Notch

The iPhone X brings a new wrinkle for developers, the notch at the top of the screen. The notch houses the True Depth Camera sensor. The notch actually protrudes into the screen and creates two areas that cannot really be used for anything. If a developer has decided to hide the status bar, there could potentially be option available for usage. However, for most developers they do not do this and will need to accommodate a bit within their application.

Apple has indicated that developers should "embrace the notch". This means that they should not attempt to hide it with black bars. Apple made this decision, not only because it would create a lopsided application, and it would, but also because iOS 11 on the iPhone X utilizes the areas to the left and right of the True Depth Camera are where users access Notification Center, on the left, as well as Control Center, on the right.

If your application is using standard UIKit elements, those elements should automatically extend up to the notch and if you have any colors applied, those should also extend to the top as well. If you do have custom controls, you will need to extend your colors up to the status bar, to provide a more consistent look and feel to your application. One aspect that is new to iOS 11 directly relates to the iPhone X and that aspect is Safe Areas.

Safe Areas

Due to the notch it is important for developers to be able to know just how their applications will function. Until the iPhone X, if a developer chose to support all orientations, they could be reasonably reassured the they would only have two potential layouts to deal with, one in portrait orientation and one in landscape orientation. The iPhone X adds a bit of complexity to this arrangement.

One of the most important aspect to any application is the content. In order to provide developers with the confidence they need when building their apps, Apple introduced a new concept with iOS 11 called "Safe Areas". Safe Areas, are just as they sound, they are areas where it is safe to put content.

Safe Area Guides are the actual term used to describe these areas. Safe Area Guides can be used on a controller by controller basis. Safe Areas will allow your content to stay within proper areas, not just on the iPhone X, but across all iOS devices. You can choose to allow some aspects of your interface to extend beyond the safe areas if it is appropriate to your application.

A peripheral item that developers need to be aware of, that relates to Safe Areas, is the new home indicator. The home indicator occupies a small portion of the bottom of the screen and automatically adjusts based on the background color. The home indicator will provide a significant amount of contrast so that it is always visible.

What this means for developers is that any controls need to be above the home button area. The area itself is not very large, but it is present. It is important to allow users to interact with this area. Safe Area Guides will allow developers to more easily determine where their application's content will be shown, without having to worry about customizing each interface differently just for the iPhone X.

Letterboxed

If you have an iOS application and you have not yet updated it to support the iPhone X, it may be worth your while to do so. If you do not your app will have black bars above and below the primary content of your app. This is because Apple cannot accurately determine how best to show your application. Therefore, they will present it using a compact size class, with a resolution of 375 points wide and 667 points of height, or 1125 pixels by approximately 2000 pixels.

While it will take some time to adapt your applications to support the iPhone X doing so will allow your application look like it belongs on the iPhone X and not like it belongs on an older iOS device. For many users. having a letterboxes application may result in them abandoning that application in favor of another one that is more native to the iPhone X.

Closing Thoughts

The notch on the iPhone X is the biggest impediment for many developers to update their applications. This is particularly true for full screen applications and games. This is due not only to the notch itself and the work that needs to be done but also because their assets may not be able to scale properly due to the new aspect ratio.

Even though it may take some work on a developers' part, to update their applications for the iPhone X, in the long run it will be well worth the effort, primarily because the iPhone X form factor is not likely to be a one-off model. Additionally, having an application that looks like it belongs on the iPhone X will not only be better not only for users, but also for developers as it will mean less work in the long run. Next let us turn to another new feature, one that is not exclusive to the iPhone X, but is also present on the iPhone 8 and iPhone 8 Plus; Wireless Charging.

When one starts out creating an application, it is usually with the intent of keeping it up to date with all of the latest enhancements and changes that newer operating systems might bring. That was my intention with my apps, wwrite, wwrite - iPhone Edition, and wwriteFree. However, as many have experienced, life sometimes gets in the way.

History

Back in March of 2010, before the iPad was launched but after it was announced, I got an idea for an app for the iPad: a plain-text editor. The idea was to use the iPad for productivity; which seems to be well ahead of the curve. I submitted my app to the iOS App Store in early April 2010 and it has been on sale ever since.

I kept it up to date on a semi-regular basis after that. That was up until June of 2014. In June of 2014, right before the introduction of iOS 8, I updated wwrite and wwriteFree to be compatible with iOS 7. I did this because I knew I would be spending the summer writing two e-books, iOS 8 for Users and Developers, and OS X 10.8 Mountain Lion for Users, Administrators, and Developers, so I would not have a chance to do any updates on the apps.

Back on August 10th, 2014, I removed the iPhone version of my app, wwrite - iPhone Edition, from sale. The biggest reason for this was that it was a lot of work to update the application and not many people had purchased it. To be honest, besides the lack of sales, there is the Notes app, which is absolutely free and included on all iOS devices.

Fast Forward

Part of the reason for not getting updates was just a lack of motivation. I have been toying with doing an update for over a year. One would have been a complete re-write using Swift, but this was a bit too daunting. I must have started this at least four times, but it never got that far. It may be bad for a developer to say, but I do not use my own application that often. This is mostly due to how bad it looks like on a 12.9-inch iPad Pro. Regardless, I did still want to update it, I just needed to get the motivation and time. The final push for motivation was this exchange on Twitter.

https://twitter.com/waynedixon/status/865998697942974464

https://twitter.com/jamesthomson/status/866012536172367872

In case you are unaware, James writes an application called PCalc. You should go and purchase PCalc as well as PCalc for tvOS.

So, a couple weeks ago I decided to really get down to updating my app. When I decided to update it, I knew I wanted to use be a Universal app (one that works on iPhone as well as iPad). The second thing I knew I wanted to do was make it work in Slide Over and Split Screen, just a James suggested. So that is what I have done.

wwrite 3.0.0 now supports full Split Screen and slide over. Here are the rest of the new features:

• Now a Universal application, supports iPhone, iPad, and iPod Touch.
• Supports Split View and Slide Over.
• Keyboard Shortcuts for Save, New File, New File From Template, Help, Show/Hide file list, Do word count
• Ability to import plain-text files from other applications using the "Share Sheet".
• Fixed word count miscalculation
• Reworked Template Customization
• Jump Directly to App Settings from "Tools" drop-down
• Support for system Emoji within files.
• Other "under the hood" changes to bring everything up to date.

Pricing Model

Since its initial release in April of 2010, wwrite has always been a paid application and this will continue to be the case. wwriteFree was designed to be ad-supported with Apple's iAd platform. Since Apple discontinued their iAd platform, I have decided to change the way that the model for the two apps. wwrite will still be paid but it will have more up to date features. Whereas wwriteFree will stay free but will not always have the latest features. For instance, it does not support Slide Over nor does it support Split View.

wwriteFree has received a minor update to remove the advertising, and make it somewhat more up to date. Previously it required iOS 7, wwriteFree now requires iOS 9.

If you already have wwrite, it will be a free update. If you do not own, now is a good time to go and buy a copy.

One of the hardest things to do is predict where Apple might take things in the future. However, that does not stop one from trying. Which is what I plan to do, regarding what Apple will announce at their annual World Wide Developer's Conference on June 5th at 10 AM Pacific Time.

The Apple of 2017 is very different from the Apple of 1979. Apple today has a fair number of platforms: iOS, macOS, tvOS, and watchOS. Within each of these, there are numerous frameworks which allow developers to produce apps. Built to support these platforms are a variety of services. These services include iCloud, Apple Music, and the iTunes stores.

I am going to attempt to predict what Apple might announce at their World Wide Developer Conference Keynote on June 5th, 2017 at 10:00AM Pacific Time. Some of these items are logical changes while others are just what I hope Apple will announce.

This is the second of two posts that cover my predictions for what will be announced. This article covers macOS, tvOS, and watchOS. The first post covers iPhone and iPad.

macOS

macOS is a very mature operating system. The basic ideas of macOS have been in place since 1984 and many of the features that users have come to rely on have been added since 2001 when Mac OS X 10.0 Cheetah was released. With an operating system that is so mature, new features can be hard to come by. However, with a sibling operating system in iOS, macOS can get some new features from iOS.

Feature Parity

Back in 2011 with Mac OS X 10.7 Lion, Apple began having macOS and iOS have more features on both platforms. The biggest was the consistent naming on both platforms. I am well aware that you can only put so much engineering into an operating system every year. However, it would be nice to be able to get the same features on macOS at the same time as iOS. To be clear, there are some features that cannot be easily brought over from one operating system to the other. Additionally, there are always features that are not able to be moved over.

iMessage Apps

With iOS 10, Apple unveiled a new feature to iOS, iMessage Applications. These applications allowed for a variety of items all within the iMessage application. Some of these applications include stickers, full-blown applications, and even the ability to order food, and send money to others. One place where this is not possible is on macOS. Adding iMessage Apps to macOS would not be easy for developers, but it could be possible.

The ability to perform many, if not all, of the same functions on macOS would be very helpful for many users, as well as providing parity between iOS and macOS. With the new MacBook Pro with Touch Bar, it is possible that any Touch ID-based applications to be available on macOS. I give the likelihood of iMessage Apps being added macOS at 95%.

macOS Server

macOS Server has remaining largely unchanged since 2011 when Mac OS X 10.7 Lion. One of the stalwarts macOS Server is the "Software Update" service. With macOS Sierra, Apple announced that the Software Update Service has been deprecated. What this means is that the service will no longer get any updates. Additionally, at some point in the future the service will be removed entirely. I give the possibility of Apple removing this at 85%. If it is not removed with this version, it will most certainly be removed with the version released next year.

watchOS

Even though watchOS has only been around since November of 2014, it has received vast improvements over the last two and half years. The most significant improvement was with watchOS 3, where both battery and speed improvements were recognized, even with the original Series 0 Apple Watch.

Initially the function of Apple Watch was haphazard. The Apple Watch attempted to be a miniaturized version of the iPhone; but ultimately that proved to be the wrong approach. Now a majority of individuals use the Apple Watch as a health-tracking device.

It's hard to imagine what other improvements Apple could make. I think the most likely ones revolve around adding new health-related functions. Possibly more workout types. One feature that some have asked for is that there is an option to be able to keep the time on the watch face at all times. The ability to keep the time on the watch face all the time would be a direct

A kind of off-the-wall guess at a new feature is custom watch faces. These would be submitted via Xcode and would be submitted to the Apple Watch store. Submitting Apple Watch faces could work in the same manner as iMessage Stickers work now.

I give the likelihood of new workout types to be 70%. The probability of the watch face showing the current time all the time at 80%. I give the probability of third-party Apple Watch faces at 50%.

Health Data

With the biggest use of the Apple Watch being health-related. There are many who wish to be able to synchronize their health data between devices. I fully agree with this sentiment. Specifically, I would like to have the Health Data be synchronized between all of my devices, including macOS. The reason for this is that I may want to view my health data on other devices, besides my iPhone.

If Apple were to do this, it would possibly put user's health data at risk. Health Data is doubtlessly the most personal information that is stored on an iOS device. If Apple were to do this, they would require it to be opt-in, and probably require two confirmations before allowing the synchronization to occur. Given this, the likelihood of it occurring is very low. I think it is about 10%.

There is one other thing that would be nice from the Apple Watch and Health data. I would like to see indications from the Health app when there are anomalies with heart rate. In particular, if my heart rate spikes while not in a workout, it may be something I want to know about. The health app could do a local notification to indicate that something may be amiss. A similar thing could be done for other types of health data as well. I give this a 25% chance of happening because it would be a logical next step for looking at health data.

tvOS

tvOS is the most nascent operating system that Apple has developed. With being the youngest, it is possible that tvOS has a lot of room to grow. The downside of this though, is that tvOS is a pretty focused product, given that it is aimed at the largest screen many people own, their TV. Despite using my Apple TV for almost all of my tv and movie consumption, there is not a whole lot of functionality that I can see being added. Despite this, there is definitely room for improvement.

The only change that I can see is not directly related to tvOS, but the content. It would be nice to see 4K TV Shows and Movies available for purchase via iTunes. The downside of this is that it would require a new Apple TV box, but not necessarily an entirely new version of tvOS. I do not necessarily see Apple doing this at WWDC, this is more of a consumer-oriented item. Given how much I do not think this will happen, I think the probability of this occurring at 5%.

TV App

With tvOS 10, Apple announced the release of a new application, TV. The TV app is designed to provide you with recommendation of what to watch next. This information comes from your iTunes Library as well as any third-party applications that allow integration. This is an area where Apple could greatly improve.

There has been some concern about the lack of expansion of the third-party integration of the TV App. What Apple could do is provide even better support for third-party services.

iTunes

On the subject of iTunes, there is one major thing that I would LOVE to see, but I do not know if it will occur; a revamped iTunes. iTunes has become such a behemoth of an application. iTunes original intent was as a syncing mechanism back when all of our media was locally on our computers. That was back in 2001. 16 years later times have changed and while a percentage of individuals still synchronize their music to their computers, that number is a very small percentage. It would be nice to see Apple completely re-think iTunes. One of the hinderances from this occurring is that iTunes is also on Windows. However, Apple could give macOS a boost by providing an even better experience and keeping iTunes on Windows the way it is now.

The biggest change would be to separate out the classic iPod syncing portion to its own application. This would still allow those individuals who need to synchronize their items to be able to do so. Meanwhile, the remaining functions, Music, Podcasts, Movies, TV Shows, iTunes U, and Apps could all become their own applications. This approach would allow each of these applications to be updated on their own schedule. Alongside this, each application could have a user-interface which matches the functionality of that application.

There are two aspects to this prediction. The first is that Apple will preview a refreshed iTunes. The second is that it will be released "in the fall" (meaning when the new iPhones are released). I give this a 10% chance of happening. It is a slim chance, but still a chance.

Let me recap what my predictions for what will be unveiled at Apple's WWDC Keynote.

Final Thoughts

Each new version of macOS and iOS include a slew of new features. This is not only because new features generate buzz and excitement, but also because new features can spark new ideas from developers. When the occurs the entire eco-system benefits. Apple benefits by increased usage, developers can profit from the features, which Apple also benefits from. Finally users get some updated applications and new capabilities on their existing devices.

Having been an iOS user since the beginning, I have seen the feature set grow from a very limited set to a very feature-rich operating system. However, that does not mean it is near complete, quite the opposite. I have been using macOS full-time for a decade now, and while its feature set was largely in place, it still has a lot of room to grow as well, just in different areas.

I do not know if any of my predictions will actually come to fruition. I guess we will see what Apple does unveil at their WWDC Keynote on June 5th, 2017 at 10:00AM Pacific.

One of the hardest things to do is predict where Apple might take things in the future. However, that does not stop one from trying. Which is what I plan to do, regarding what Apple will announce at their annual World Wide Developer's Conference on June 5th at 10 AM Pacific Time.

The Apple of 2017 is very different from the Apple of 1979. Apple today has a fair number of platforms: iOS, macOS, tvOS, and watchOS. Within each of these, there are numerous frameworks which allow developers to produce apps. Built to support these platforms are a variety of services. These services include iCloud, Apple Music, and the iTunes stores.

I am going to attempt to predict what Apple might announce at their World Wide Developer Conference Keynote on June 5th, 2017 at 10:00AM Pacific Time. Some of these items are logical changes while others are just what I hope Apple will announce.

This is the first of two posts that cover my predictions for what will be announced. This article covers iPad and iPhone. There will be a second post next week that covers macOS, tvOS, and watchOS.

iPad

One of the areas where Apple needs to make some major improvements is with the iPad. While the iPad is no where near as popular as the iPhone, it is still a major part of Apple's strategy. The iPad has seen some improvements over its seven year life, however any iPad-specific improvements have been lacking in the last few releases. In particular, improvements that would help the 12.9-inch iPad Pro.

The biggest improvement that could be made is around the way that multiple applications are handled. When you use multiple applications on the iPad Pro, you can swipe from the right side of the screen to bring up any compatible applications. However, there is no real order to the applications. This makes it quite difficult to be able to easily locate the application that you want to use in split view.

One possible solution to this issue is to reduce the size of the icons, and basically make it an alphabetical list with application names. This could be an option that is just at the top of the screen. My guess at the probability of this behavior changing is 100%.

Switching Applications

Switching applications on the iPad, particularly in split view is rather cumbersome. If you want to be able to switch the left and right applications, you have to perform the following steps:

1. Expand the application on the right all the way to the left.
2. Use slide over to bring up the list of possible applications.
3. Locate the application that you wish to use (see above for issues wit this).
4. Tap on the application that you wish to use in split view.
5. Drag the right-side application to the size you wish to use it at.
6. Tap on the divider button to put the application into split view.

This procedure takes six steps to be able to accomplish. What would make for a better user experience is to be able to easily swap the two applications. This could be accomplished by holding down on the divider between apps that are in split view. A popup could appear and would offer to swap the applications. I predict the possibility of this occurring at 75%.

App Groups

It is quite often that when you are using applications in split view, that you wish would automatically be grouped together. This could be applications like "Twitter" and "Slack", or "Notes" and "TV". However, this is not possible under iOS 10.

It would be nice to see this feature for iOS. This solution could be something akin to Spaces on macOS. With Spaces on macOS you are able to assign applications to a specific space, and the application will also show on that space. This means that you can assign applications that you want to group together to the same space. Given that it is iOS, there is likely a limit to the number of these "spaces" that could be configured. If Apple were to add this feature, it would go a long way for the "pro" users. I give the likelihood of this occurring is 50%.

Within Apple development, there is this idea of application groups. These "application groups" are ones that allow shared information between different applications from the same developer. That is not the type of application grouping that I am referring to.

Sharing Information Between Applications

One of the downsides of split screen on the iPad is that if you want to share information between the two applications that are currently on the screen. If it is simply text that you want to transfer, you can copy and paste. However, if there is an image that you want to send to the other application, you must use the share sheet.

It would be helpful if someone could easily drag and drop information from one application to another. This behavior is very prevalent in macOS applications. There are instances where the items that are dropped from one application to another result in garbage, but this is to be expected.

If Apple were to add this type of functionality, it would be a huge boon to the professional group of iPad users. Additionally, this would add some more functionality and provide more of a replacement for a wider range of users. I put the likelihood of this occurring at 25%.

Swift Playgrounds

When Swift Playgrounds was first introduced it was touted as a way to be able to test out applications and develop directly on the iPad, albeit in a limited manner. There may be some point in the future when you are able to fully develop applications on the iPad, however we are a ways off from that. I do think there will be one change to Swift Playgrounds; the ability to create Sticker Packs directly on the iPad.

Sticker Packs are available for iMessage and allow individuals to quickly create stickers and submit them to the store. There is absolutely no coding required to create a sticker pack. With the Apple Pencil and the iPad Pro, there is a large contingent of artists who would love to be able to create and publish their sticker packs directly from the iPad.

Right now, Xcode is required to be able to publish these sticker packs. However, if Apple updates Swift Playgrounds, or creates an entirely new application, it could allow even more sticker packs.

The update, or application, would only allow sticker packs, not more full-featured applications, so it could be possible to allow this to happen. I think the likelihood of this occurring is about 30%.

iPhone and iPad

There are many aspects to iOS that are shared amongst the iPhone and iPad. Whereas the iPhone was the first product released, it was not the first product to enter development, that was the iPad. When the iPad was released it was actually a different operating system. The features between the iPhone and iPad did not come together until iOS 4.3.

32-bit applications

One of the likeliest features of the next version of iOS are that 32-bit applications will no longer be supported. If this does come to pass, there are a couple of ramifications.

The first result is that there will be a couple of devices that will no longer be supported. Most notably, the iPhone 5, iPhone 5c, and the 4th generation iPad. This is not anything new, given that devices eventually do become end-of-lifed.

The second result is that any applications that are 32-bit only will no longer run. This means that applications that have not been updated will stop working. A majority of these apps are games, which could become problematic for some of your favorite games. I give the possibility of this occurring at 90%.

Naming

Last year's release of iOS 10 and macOS 10.12 Sierra were both quite substantial. If there is any time that Apple would change from the "10.x" series of names, this would be it. Now is an excellent time for Apple to name the next macOS as macOS 11 [code name], and next years would be macOS 12 [code name], and keep the numbering going forward. This could allow for individuals to more easily know which versions of the operating systems work best together. While it is possible for newer versions of macOS to work with older versions of iOS, and newer iOS versions to work with older macOS versions, the operating systems work best when they are updated to matching versions.

Along side this, Apple could also start providing names to iOS versions. Ideally, these names would be the same. By doing this, users could more easily identify which version of each operating system that they are using and this would also allow users to easily know if they are running the same versions. This is merely an idea. I give this a 5% possibility. I also give the probability of iOS and macOS having the same version going forward as 5%.

Possibility Recap

Let me recap what my predictions for what will be unveiled at Apple's WWDC Keynote.

Final Thoughts

Each new version of macOS and iOS include a slew of new features. This is not only because new features generate buzz and excitement, but also because new features can spark new ideas from developers. When the occurs the entire eco-system benefits. Apple benefits by increased usage, developers can profit from the features, which Apple also benefits from. Finally users get some updated applications and new capabilities on their existing devices.

Having been an iOS user since the beginning, I have seen the feature set grow from a very limited set to a very feature-rich operating system. However, that does not mean it is near complete, quite the opposite. I have been using macOS full-time for a decade now, and while its feature set was largely in place, it still has a lot of room to grow as well, just in different areas.

I do not know if any of my predictions will actually come to fruition. I guess we will see what Apple does unveil at their WWDC Keynote on June 5th, 2017 at 10:00AM Pacific. Look for another article about macOS, tvOS, and watchOS coming soon.

While it is possible that Apple makes changes for developers outside of their World Wide Developer Conference, it does happen. Apple has made a few changes over the past two weeks that directly affect developers. These revolve around TestFlight, Search Ads, and Photos.

Test Flight Changes

Test Flight was acquired by Apple in February of 2014. Prior to purchase, Test Flight was capable of testing both iOS and Android applications. To no one's surprise, Apple quickly removed support for Android. As of February 2015, Test Flight, in its standalone capacity, was shutdown. Since then, Apple has slowly added some new features, but they have been modest. The most recent changes expand the service's capabilities.

One of the downsides that many developers have brought forth include the limitation of only allowing one build to be available to testers. While this approach may work well for testers outside of a company, inside the company it is often more beneficial to be able to test more than one build at a time. Test Flight now supports multiple builds, for both internal and external testers. When this is enabled, testers will be presented with multiple builds. The testers will need to choose which build to test, but the option is now available.

The second change for Test Flight revolves around testers, specifically grouping testers. As mentioned above, there are often times when a developer would like to be able to test multiple features. With the new multiple builds option, it is possible to test multiple builds, however each user who wants to test a specific build would need to be manually selected each time that a new build is to go live. This is no longer the case. Test Flight now supports grouping testers.

The grouping of testers now means that when there is a new build of an application, the developer can simply assign that build to a specific group. This streamlines the process that developers must go through when they wish to submit a specific build to a set of users.

The primary function of Test Flight is to allow developing of an application. Once an application has gone through the testing phase, the final step is to release the build into the App Store. When this step occurs, the test build that was running no longer runs. This behavior has changed. Now, when an application that was being used with Test Flight goes live in the App Store, the Test Flight build can continue to be used. The primary benefit of this change means that there should now be minimal interruption when an application goes live.

These are all of the changes that have been made to Test Flight, but these are not on the only changes that have been made. Next let us look at Search Ads.

Search Ads

Search Ads were introduced last June, the week before Apple's World Wide Developer Conference. Search Ads are advertisements that developers can purchase and appear within the App Store application. At their launch, Search Ads was available only in the United States. As of Tuesday, April 25th, Search Ads will be available in a few more countries. These countries are the United Kingdom, Australia, and New Zealand.

While the number of countries that are included is still small, being able to work out the bugs in the system, before doing a wider roll out makes sense. It is entirely possible that this is Apple's strategy. Alongside this, different countries will possible require different layouts given the difference in character types, as well as widths. This is a good start for future expansion.

Live Photos

At their September 2015 event for the iPhone 6s and iPhone 6s Plus, Apple introduced a new feature, Live Photos. Live Photos are photos that allow motion. In reality, these are quick movies that have some photos on each end of the movie. One of the issues with Live Photos is that they do not work on anything other than iOS and macOS. This is no longer the case. Apple has released a new Javascript Framework, LivePhotoKitJS. This framework allows any website to be able to load and play Live Photos.

What this ultimately means that sites like Twitter, Facebook, and Instagram can all display any Live Photos that have been taken to other users. Once these sites do add this ability, it will go a long way to do making Live Photos available for everyone. Besides having big developers implement the feature, this is a way for other non-Apple developers to be able to display Live Photos within their applications as well.

If you go to developer.apple.com/live-photos/ you can see an example of the Live Photos Javascript framework in action. Apple has used it on their own website to show off a couple of Live Photos. Full documentation is also available at developer.apple.com.

Final Thoughts

While these changes only affect developers directly, there will be some smaller benefits to all users. With the Test Flight changes, this means that developers can focus on more than just one feature or update at the same time. With Search Ads, more developers will be able to get their applications in front of more users. With Live Photos Framework, the richness of the web has been expanded to allow an even better experience for everyone.

I have spent the last few weeks thinking about programming, specifically variables, and how to name them. There are many different approaches to naming variables. One of the ones that is bandied about, and question quite often, is the Hungarian Notation. Hungarian Notation is the idea of putting the type in the name of the variable. An example of this might be "str" for string, or "int" for integer, or "bln" for boolean.

Conversely, there are those who never put the type within a variable name. Examples of these variables names might be "firstName", "zipCode", or "countryCode". These three examples are somewhat basic and most people can infer what type of information is going to be stored in these variables. However, there are times when it may become less obvious. For example, the variable "userID". What type of data is stored in this variable? It could be an integer, to tie a user to a database row, or it could represent a username, like "bob123".

The debate between the naming conventions used leads to this question "When is it appropriate to use each type of naming convention?" Well that depends on many factors. For me, the biggest is which programming language am I using. When I am using Objective-C, the type of variable must be declared.

Objective-C

With the three variable names above, it would be quite obvious what type the variables represent. However, when I use PHP or Javascript, it may become less obvious. In PHP, you can specify what type, but by default all variables are just that, variable. No keyword or type information is assigned. They can contain any information and be of any type. See the code below.

PHP

As a person looking at the code, you cannot explicitly know what type of information is expected. You can infer but you do not know with certainty. If you assign the wrong type of data to the wrong variable, it can completely break an application. The same is for Javascript, where the only way to declare a variable is using the keyword of "var".

Javascript

With PHP, and Javascript, Hungarian Notation becomes quite handy. When using Hungarian Notation, your code may look like this:

Javascript

As you can see, you can more readily discern what type of information is being expected. Now that one situation when to use each type of notation is answered, the next question becomes, "Why have different naming conventions?"

The answer to this one is quite simple, readability. With the proliferation of open source projects, there are many individuals who try to understand how an application or program actually functions. To make it easier on them, it is best to use some sort of convention, when it is appropriate. Besides the benefit of other individuals, as a developer it also makes it easier for you to read your own code later on.

As an example, my largest web, which has about 175 database tables, has a total of 107525 lines of code, between PHP, HTML, CSS, and Javascript files and all of this spans almost 1500 files. A good chunk of this code was written almost six years ago now. If I were to look back at some of the original code and did not use Hungarian Notation, then I would most likely have to look back at certain things and re-construct what I had written. While this almost certain to happen regardless of how long ago a piece of code was written. Nonetheless, it does take away from current productivity and forward momentum.

I am not advocating that everybody use Hungarian Notation, but merely to think and plan ahead for when you have to come back and look at code. Additionally, if you are looking to open source your code, be sure that it is readable to your audience. This means, somebody besides yourself. Also, do not forget comments, even if they are basic so that everybody can get some idea of what is the intention of a certain bit of code is meant to accomplish.