Menu

One voice. Our voice. Cogent voice.

Category Archives: iOS

WWDC 17: Why am I excited as a developer?

It’s been a week since WWDC and I finally got time to write this blog post to express my excitement as an iOS developer. I won’t be talking about the keynote, since it’s pretty much the same every year. Instead, I’ll be focusing on the real deal, WWDC 2017 Platforms State of the Union.

For the non-iOS-developer readers, Platforms State of the Union is a session in WWDC that gives attendees a more technical overview of what’s coming to Apple’s platforms, as its name suggests. Just like previous years, Apple made some really big announcements to its developer community. Let’s see some of my personal favorites.

Xcode 9 Source Editor

As an iOS developer, I use Xcode everyday, which sometimes can be a pain. Xcode’s performance and features are not that strong comparing to some of the competitors. This year, Apple introduced one of the most welcoming changes to Xcode in my opinion – they have re-written the whole source editor from ground up in Swift! The result? 3x faster file opening seed, 60fps scrolling and up to 50x faster jump-to-line action. On top of that, they also implemented an integrated markdown editor, improved coding issue presentation and tokenized editing. What’s even better? A brand new refactoring engine and workflow that is powered by an open-source transformation engine. IntelliJ users may not be that impressed with these improvements. But to me, the all new source editor will give me a huge boost in productivity. I can’t wait for it to come out of beta… (Rule of thumb, don’t use beta Apple softwares on production development works.)

Swift 4

Not surprisingly Swift 4 will be there with Xcode 9. Apple has vastly improved one of the most widely used classes in Swift, String class. In Swift 4, String is now a range-replaceable bi-directional connection, meaning it behaves and can be used like an array of characters now without any sort of conversions. Thanks to the underlying improvements, String now provides 2.5x-3.5x faster processing depend on the language it’s in. Another welcoming news is the introduction of “codable” type. The new type will be synthesized by compiler and has the ability to perform 100% type-safe JSON encode/decode with only one line of code. Apple also made it easier to adopt Swift 4 in Xcode 9. The compiler now supports both Swift 3.2 and 4.0 and allows developer to mix-and-match 3.2 and 4.0 targets. All these improvements makes Xcode 40% faster building large mix-and-match Swift/Objective-C projects. Moreover, building projects using multiple Whole Module Optimization targets is now 2x faster!

iOS 11

One of the biggest announcements in WWDC 17 is iOS 11. For users, iOS 11 blurs the line between a desktop and a mobile OS, which will finally make iPad Pro a viable productivity tool. For developers, this means new APIs to play with. Starting with the new Drag-and-Drop feature, Apple did a phenomenal job making it easier to integrate in apps. It’s automatic for text and web content, and has delegate protocols for customization similar to other iOS APIs. With its cross-process, system-wide multi-touch support and built-in data security, I’m sure developers will start to provide this new feature in their apps to users as soon as iOS 11 becomes available.

Good news for everyone

Along with Xcode 9, Swift 4 and iOS 11, Apple also introduced CoreML for machine learning, Metal2 graphic engine and ARKit for virtual reality. These are only a few that caught my eyes. I am really excited to learn more about CoreML and hopefully can put it to use in one of our apps someday. I truly think Apple has given us developers really good tools and platforms to provide users best features and experiences. This is good news to developers as well as users. A better Apple will surely push its competitors to step up their game, which is something I really like to see. Whether or not you’re a developer or iOS/macOS user, you should be excited too. As consumers, we will always benefit from the competitions.

The other day I came across a bug when I tried to use Key-Value Observing to observe the change of a property in some not-so-modern Objective-C class. The observer was never notified when the property’s value changed. It took me a long time to figure out what was wrong and I just want to share my findings, so you don’t have to be upset should you ever run into a similar situation.

It all started with a simple “@synthesize” statement.

Some background first. In “Adopting Modern Objective-C” document, Apple recommends using properties instead of instance variables (or iVars) in “as many places as possible”. One of the benefits listed is “Auto-synthesized getters and setters”. If you still remember all the “@synthesize” statements in stone-age of Objective-C, I believe you will just love auto-synthesizing feature in modern Objective-C as much as I do. (Almost) No more “@synthesize”! Isn’t that sweet?

Even though synthesizing is no longer required (most of the cases, and usually not even recommended), you can still use it to synthesize a property with a backing iVar (Compiler will create an iVar with the same name of the property if there isn’t one created by developer.) and custom setter and getter. However, if you don’t make your setter KVO-compliant or just simply ignore setter and change backing iVar’s value directly, KVO will obviously fail to observe the change in property’s value.

A well-designed custom setter or a setter created by auto-synthesizing calls “willChangeValueForKey:” and “didChangeValueForKey:” methods at appropriate moments to send observer notifications so that observers that implements KVO methods know when a property is changed. If new value is directly assigned to a backing iVar, the setter is never called and hence there will be no notification sent for KVO. Not only will your own KVO code not work, any framework you may have used in your project that depends on KVO will also not work.

You can find a demo project here. In the demo, if a property’s value is modified without using the accessor (setter in this case), KVO won’t be able to observe the change.

Enhanced Spotlight: I actually didn’t know you couldn’t check weather and search things with your own words with Spotlight in Yosemite.

Mail App: I’m gonna write emails to all the people I know with all the tabs I can have in new Mail app’s compose window and still ignore emails from Phil Schiller because I can search for all emails I ignored from Phil!

Metal for Mac: RIP Open GL… While the PC gamers are playing GTA5 with awesome graphic, Mac gamers are still stuck with games like vegetables vs zombies. Let’s see if these big game companies can convince PC gamers to buy Macs.

Have I mentioned that El Capitan is faster than Yosemite?

iOS 9 and WatchOS 2

Siri now has a new animated interface. I wonder what will you see if you look at it with red-blue 3D glasses…

Siri can also do way more than it (she?) could before based on its (her?) soundings.

“🎵It sees you when you’re sleeping… It knows when you’re awake…🎵”

Like in OS X, Spotlight on iOS has received a new interface and can now look into your apps for search results.

Apple Pay now works at more places than ever! And apparently Apple and Google seem to have reached some agreement to switch the names of their payment app. Yes, I’m looking at you, Android Pay and Apple Wallet.

Happy drawing in the new Notes app!

Maps app can now tell us which bus/train to take to go to places!

Apple now lets you choose what news you wanna read in its new News app, as long as you’re in US, Australia or UK.

People have been asking for an “iPad Pro” for some time now. Apple’s answer to it is a new QuickType keyboard with shortcuts plus touchpad capability and a more powerful multitasking feature (Samsung, get your lawyers ready!).

You’ll be able to use the awesome Picture in Picture and Split View feature if you have the latest iPad Air 2.

Swift 2 will be open source later this year, available for iOS, OS X and Linux. I feel sorry for Windows because it won’t get all the wonderful new features comes with Swift 2.

It seems like WatchOS 2 can finally do what it suppose to do a long time ago. Apple has finally given access to normal frameworks and features like animation & layout for Apple Watch.

Everything about Music

For $9.99 a month, you get another Spotify alternative. That’s it.

And the crazy developers at Apple are developing an Apple Music app for Android as well!

Overall impression
I am not happy about this keynote and it’s not because there’s no new Apple TV or other new toys. WWDC is a developer conference and it should focus on new operating systems and SDKs, not music. Unlike previous years’ WWDC, Apple rushed through announcements and demos and spent what seems like forever for their new music streaming service. I understand it’s important business for Apple but they really should have spent more time talking about WatchOS 2 and Swift 2.

It’s been a long time since the second part of this series was posted. Hopefully my experience on note taking is helpful. In this final part of the blog post, let’s talk about how a developer can evolve from “just being a developer.”

Sky’s the limit

It’s common sense to keep learning for professions like developer. I’m at no position to tell someone what he/she should learn but I think there really shouldn’t be any limit on what a developer can learn. Making an app from scratch involves efforts from different aspects such as design, project management and so on… For instance, basic image editing skills are easy to pick up and will make things way easier when you want to make some small changes to an image you want to use in the app. And knowledge on project management can help you better plan and estimate your development work. In my opinion, having those knowledges and skills can be extremely useful for any developer works independently or in a team. After all, you don’t always have a graphic designer or a project manager in your team.

Always something new

iOS (or Cocoa in general) developer community has been active for a long time and there’re tons of awesome things that satisfy all kinds of needs for developers. For example, ReactiveCocoa framework provides additional APIs for functional reactive programming using Objective-C. And tools like Reveal makes tasks such as debugging user interfaces much easier and efficient. The geeky side of me always like to spend free time to discover and play with new frameworks and tools. It’s an interesting way to learn about new coding styles and enhance your own apps from those open source frameworks. I usually visit Ray Wenderlich’s tutorial website, NSHipster and objc.io to learn about new frameworks and tools. Websites like CocoaControls are also good places to discover UI related frameworks.

One for all, all for one

We benefit a lot from other developers with all their fantastic works on different frameworks and tools. As members of the developer community, we should give back to the community and help other developers whenever we can. Contributing to open source projects and answering questions on websites like Stack Overflow are good ways to learn from other people. We can learn about types of issues other people encountered and discuss different approaches on fixing all kinds of issues. Moreover, having a good profile on GitHub and Stack Overflow also makes you stands out from other people when you try to find a new job.

Where to go from here?

It’s actually never possible “just being a developer.” Sometimes you have to be a graphic designer or a project manager. And if you want to, you can also be an adventurer, a contributor or a tutor. Let us know in comment section what you think about this series and what other topic you want to see in the future.

In Part One of this blog post, I mainly talked about how I got started with iOS development and some ways I find useful for learning iOS development. At the end of Part One, I also promised to share a habit of mine that has benefited me a lot on iOS development. If you haven’t read the last part yet, you can find it here and see if my experience can be a helping hand to you. Otherwise, sit back relax, grab yourself a drink, and let me unveil my secret habit on iOS development.

The Situation(s) and The Solution

Have you ever encountered a bug in your app that makes you think you’ve seen it somewhere before (but you forgot how you solved it)?

Have you ever worked on an old project of yours and wanted to travel back in time to hug yourself or beat yourself with the keyboard?

Have you ever wanted to mimic a design from an app or a library but forgot which app or library is it from?

I have been in all those situations and even more. Every time I’m in those situations, I wish I could remember but I simple can’t. I think as normal human beings, our memory is highly limited and new things will replace old ones as time goes. Therefore there has to be a solution to this. For me, it’s simply to write down things I want to remember. Yup, it’s just taking notes.

What to take notes for and how do I learn from them?

I’d like to approach this from a leaning perspective. I usually take notes for the mistakes I made, the projects I worked on and the tricks or designs I leaned from other apps or libraries so that I can learn from mistakes, past and others.

Taking notes on bugs I encountered and solutions to them makes me able to learn from my own mistakes. It can be a boring task but I guarantee that you will not regret doing it. Sometimes I may find a bug that I’m 100% sure I had some time before. But I just can’t remember how I fixed it last time. If I don’t have my notes or for some reason it is not in my notes, I have to go through the process to fix it like a new bug, which can be a pretty time consuming and frustrating task. However, if I can find it in my notes, everything becomes much easier. Taking notes on my own mistakes has greatly reduced the time for debugging and the number of mistakes I may make while coding.

Just like learning from my old mistakes, I review my old projects on a regular basis and make improvements (or upgrades) if needed. While reviewing the old projects, I take notes on the bad designs I find and changes I need to make. This can keep my projects as well as my brain up to date and with the notes I can be more mindful when working on my next project. The notes make my projects more “future-proof” so that I can love, instead of hate, myself more when I have to come back to work on an old project.

In addition to taking notes on my own mistakes and projects, I also spend time checking out interesting apps and libraries from other developers. I take notes on things I want to do or use when I see them in other people’s apps or libraries. Therefore, I always have some sort of reference when I need them. I spend time checking out apps in App Store’s top lists as well as other popular and award-winning apps every now and then. It’s a good way to learn what kind of design is trending and it also gives me a rough idea on what users want from a developer’s perspective. I learned even more from open source libraries and projects. The source codes themselves can give you a pretty good picture on other developers’ design style and some good practices. And the issues page of the project is a good place to see what kind of issues other people had and learn something from how they solved it. Try to start with some popular and well-received open source projects. They have more people contributing to them and usually have some pretty good documents to help with learning.

Where to go from here?

Taking notes is a habit that is simple yet hard to keep. It is also a small habit that can make big difference. Leave a comment and let us know if this blog post is helpful to you. We will be also happy to hear from you about your development habit and how it helps you. Make sure to check back on the last part of the blog post, which I will share my thought on how a developer can evolve from “just being a developer.”

Tunnel Vision

For those of you who may not have been following, Apple has been getting a lot of flak for the build quality of their iPhone 6+s. The phenomena has been aptly been dubbed bendgate. So what is the root cause? Is Apple at fault? How does this affect Apple in the grand scheme of things?

A Little of This, a Little of That

According to Apple, only a low number of phones have been reported to have bent. So in theory, the end users of the iPhone 6+ are simply breaking the phone through excessive use. Truthfully, only time will tell, as the new pair of iPhones have barely been out for a month. On the flip side, if we say that the structural composition is compromised this brings up an interesting argument. I personally believe it’s a mixture of both.

Misconceptions

A lot of people are blaming the aluminum alloy of the phone. Certain users argue that it is actually the actual problem is the geometry of the phone. In other words, the physical structure of the phone is somewhat compromised. To be more precise about it, the stress is concentrated right at the bottom of the volume rocker. Even if Apple opted for a harder aluminum alloy, the point of failure would have still been the same.

If you look at other phablet devices like the Galaxy Note 3, they don’t bend. This is not necessarily because of the Note 3’s magnesium alloy chassis, but because of it’s I-beam shaped cross sectional frame. (You know, the same structure that holds up the foundations of buildings.)

Moving Forward

Was Apple blinded by the chase of the super thin phone? Yes. Were users who experienced issues with their devices somewhat wreckless? Perhaps. While we aren’t sure what percentage or number of people will experience bendgate first hand, perhaps putting a giant phone in your pocket isn’t the best idea. All we can really do is make sure to learn from those lessons and move on.

What can we learn from this fiasco? Well obviously for the hardware designers, don’t forget that engineering has it’s place in product design too. However, this lesson also can be extrapolated to companies like us at Cogent. Even though we don’t design hardware (yet?), we can take Apple’s oversight as a healthy reminder to not be blinded by tunnel vision when considering the design of our products.