Mobile Architecture Going Right and Wrong

Most decisions have positive and negative outcomes. When it comes to choosing what technologies to use for a software development team, it often comes down to two different “right” choices. They are right for different reasons and optimize for different things. A smart move is to optimize those things which serve peoples’ best interests (and the interests of their company) even at the expense of other concerns.

Imagine this situation brought to my attention: A team member observes upcoming code duplication between two systems down the road between an iOS and Android product. Among other things, they point out a technological solution that involves adding an additional language that would let them share code between iOS and Android.

From that single point of view, a solution like that sounds OK. Yet, what are the consequences? As you would expect there are pros and cons.


Let’s start with the cons. Adding new things to a technology stack of this kind may cause the following things:

  • Overstressed team by spreading the team too thin
  • Integration overhead
  • Expertise silos
  • Resistance to refactoring
  • Unforeseen issues due to an increase in overall architecture complexity
  • Increased time and pain around troubleshooting
  • Longer time to get new team members up to speed
  • Enjoyment of work going down for some and potentially all

Overstressed Team by Spreading the Team Too Thin

This deserves diving into a little. Imagine the team has recently adopted Android. Let’s say they recently also adopted a new programming paradigm such as Functional Reactive Programming. Now add a couple new team members. What’s the potential result? A magnification of the concerns listed above.


Good things that come can come from adding more to the technology stack:

  • Reduction of duplicate code
  • A new thing to learn (which can be good or bad depending on how much one has to learn currently already)


Which idea is right? Both are right in some ways and painful in other ways. As someone once said:

The hardest decisions in life are not between good and bad or right and wrong, but between two goods or two rights.

Of course decisions need to be made in part against the “-ilities” of architecture. In this case, Architecture complexity increases as one adds technologies. Lessons of the past have taught me that with the adoption of any addition to a technology stack, there can be costs to pay from an architecture and team point of view.

However, consider the people aspect of this too. The quality of a person’s life and their happiness affects productivity. So, measure decisions against those things that will make you excited about working and contributing as well. I highly suggest keeping those in mind. Otherwise, nothing will get done if you are fighting against the human nature of people seeking happiness.

Kotlin, RxJava, and Android is Fun Times 3

It’s almost springtime and time to explore new domains! So even though I still love RxSwift and Swift, I’m looking into Kotlin, RxJava, and how it relates to Android.


Kotlin makes a great first impression! Kotlin has a feel similar to Swift. The functions are denoted with fun. Also, the syntax seems lean.

Some examples are available to try online at After that, a deeper dive into the Kotlin Reference seems like a good idea.

Fun So Far .. Yet Time For an IDE

As described in the Kotlin: Getting Started with IntelliJ IDEA, I installed a plugin into Android Studio to see Kotlin work correctly. It’s a good feeling to know that I am using 1.0.0 of Kotlin. Did you know that Kotlin started in 2010?


With Kotlin knowledge and plugin installed, we move on to RxJava. There’s an insightful and well done Berlin droidcon video by Ivan Morgillo titled Android reactive programming with RxJava. In the context of the Android world, he goes over the concepts of Rx and shows some great RxJava examples.

Android Reactive Programming with RxJava

Ivan is also the author of an RxJava book titled RxJava Essentials released in mid-2015.

Looking around, I see 2016 RxJava Basics by Cosmin Stefan-Dobrin presentation slides that have some good content in there too. Two very interesting slides in there have the title: “Retrofit and RxJava, sitting in a tree.” Although outside of the scope of this article, Retrofit is worth a look.

Finally, there is an RxJava community on Glitter. Having used the RxSwift community on Slack, I know the importance of a strong and supportive community.

All together, it looks like Kotlin and RxJava have what is needed to help one be successful with their Kotlin / RxJava / Android adventure!


Guilt and the Ego Trip

Listening to Joseph Goldstein’s Dharma Talks, I found something interesting in relation to guilt. Feelings can be powerful tools for learning. However, guilt can be something that kids and adults get hung up on.

In response to doing something stupid or not nice, I know a young loved one who likes to say “I’m bad.” In his own way, Joseph points out that a person can sometimes get hung up on the story of being bad as opposed to learning from the experience and then moving on.

14:12-ish into his “2015-11-18 Q & A” Dharma Talks, he talks about how we often “justify guilt” in a way that’s not useful. He also points out a technique of “wagging the finger at [guilt]” at 15:07. In other words, he points out that we can notice this unhelpful guilt. It can be identified. We can then change it into “a feeling of wise remorse”, take responsibility and do all of this with understanding.

How to share this concept with a child? My initial thought is to do it with a picture.


Image from BK at

Good luck with your exploration of how to internalize this idea and share this concept with both the young and old.

10% Happier App Is Growing

The 10% Happier: Meditation for Skeptics app, which I originally covered in Meditating on Meditation Mobile Apps, has been growing by leaps and bounds in both value and content.

In the app, Dan Harris continues to ask in-depth and practical questions. However, now there is even more than one meditation expert giving answers. Originally, it was just Joseph Goldstein. He’s a fantastic, wise, and wonderful person to listen to. Now it gets even better with more teachers entering the scene.

The idea is that each meditation teacher will share valuable insights in their own area of specialization. Here’s an example. In the “10% Nicer” section in day 2, Sharon Salzberg and Dan Harris discuss “the why” of meditating on loving-kindness. In other words, why one would start and keep doing the loving-kindness meditation. Together, Dan and Sharon do a great job emphasizing the value in a person’s own personal experience yet also highlighting the importance that science brings. In his own funny way, Dan points out that meditating on loving-kindness makes you nicer and less of an a-hole.

The video interviews are funny. I cannot emphasize this enough. The comical and frank video interviews between Dan Harris and the meditation teachers have been wonderful. The followup guided meditation recordings have been instructive and highly useful. It’s through these you learn by actually experiencing meditation.

Finally, there is the coach. From my own experience, there is no substitute for having a coach that you can send SMS messages to. Having first started meditating decades ago, I have some experience which seems beyond introductory. Yet, I am amazed at some of the new things I have learned and received clarity on.

To learn more, you might want to listen to the OneMind Meditation podcast titled “How To Be 10% Happier with Bestselling Author Dan Harris.” It does a great job covering the journey of the book author which eventually led to the creation of the 10% Happier app. During the recording, credit goes to Dan Harris for pointing out that the company, Change Collective, which built the app is made up of fantastic people. From my personal interactions with them, I would have to agree.

If you’d like to stay up-to-date, you can follow them on twitter at 10% Happier.

If you become hooked like me, please pay it forward and let others know about it. Just imagine if the world was 10% happier or 10% more at ease and loving.

Adventures in Creating iPhone App Store Images

The iPhone app is made and you feel ready to ship. However, you need to get the iPhone app screenshot images into the App Store. When you work at a great place like CARFAX, there are other awesome people who do that quite well.

When doing it on your own, it’s no small feat to make and upload images for your iPhone app that are decent. Sure, one can just grab a screen shot of the app and shove it up there. However, high quality images that evoke an emotional response and reveal interesting parts of your app are best.

Some questions came to mind while I was going through this process:

  • How to create a screen shot of the iPhone app without the status bar?
  • How to have the screenshots look fancy like the Clear or CARFAX mobile apps?

By fancy, I mean have the screenshot surrounded by an iPhone image that is appealing.

Possible Solutions

Let’s quickly go over some possibilities I first ran across. At first glance, looked promising. Searching on was another possibility. If all else failed, I was going to back to the Ray Wenderlich tutorial to dig up another answer. had real promise. I found out about it from the Ray Wenderlich tutorial. has lots of variety in their images. After playing around with it for a long time, I found an image I liked but it didn’t seem like a drop in solution for use in the App Store. Since the variety is fantastic, I may go back to it later for some of my website marketing. For app images though, I eventually decided to start out with something simpler.

This site has a simple and easy to use interface. I like how they have things set up so that you can use PayPal and codes to get your purchase. After playing around, I came up with an image I like. So how many images do I need? Five images for four phone sizes came to twenty images. Each image would cost a few dollars. Hmm. Can one do better?

Ray Wunderlich Tutorial

The tutorial title is How to Make Great App Store Screenshots. It’s a good tutorial. It introduced me to several different options. The last time I saw this tutorial I skipped down pretty quickly to the Photoshop solution so I hadn’t deeply checked out the other options.

Random Thoughts

While going through the tutorial and seeing how much time I spent on all of this, I started having some random thoughts. Thoughts like:

  • Why is this taking so much time?
  • There’s clearly a market for iPhone pictures for the app store.
  • Why do I see typos wherever I look? For example, Screenshot Maker Pro has some serious grammar errors here.

After I got over the typos, I saw that Screenshot Maker Pro looked promising.

Screenshot Maker Pro

I had my doubts due to the typos and from what I saw on the webpage. However, trying out the app had increased my confidence in the solution. After taking a screenshot, making an image, and playing with the settings, I found something I like. However, it’s the wrong size and transparency is on. Apple doesn’t like App Store pictures with the transparency on.


So, into an image editor I go. I tried various things including a command line tool called sips.  However, I finally landed on using Acorn. It only cost me about $30. My goal was to just make a 4.7 inch portrait image that’s 750 wide x 1334 tall or vice versa for landscape. After some messing around, I got something that worked. I had to resize the image and then the canvas. I also figured out how to turn off the transparency aka alpha by using the Preview app.

With this new found knowledge, I did the other sizes. For the iPhone 4S, Screenshot Maker Pro didn’t quite work. So, I just uploaded the screenshots themselves. Sometimes you have to know when to say when and move on.

Specific Example For an Image That I Wanted as Landscape:

  • While preserving aspect ratio, I resized the image to a height of 750 pixels. The width ended up being 1089 pixels.
  • I resized the canvas width to the needed 1334 pixels

Time to get rid of the transparency. I turned off the alpha using Mac Preview’s export to PNG with the alpha unchecked.

Image Concerns

  • One of my images showed off the notification that the app sends. However, it also showed the home screen. That violates the following guideline: “Never display the Apple Watch, iPad, iPhone, iPod touch, or Apple TV Home screen or any icon or image that you do not own.” I deleted that image.
  • Looking at my other images, another concern arose. The status bar showed a specific carrier, AT&T.

To hide the status bar for App Store sakes, I found this from a Stack Overflow post:

With that I could temporarily hide the status bar while taking the screen shots. So, I redid all the images.

Acorn Again

Now with the concerns are out of the way, it’s time to reuse Acorn and fix the newly created portrait images with Acorn:

  • Resize image height to 1334 (forces width of 583 to keep same aspect ratio)
  • Resize canvas to 750 width
  • Open in Preview, export as PNG, uncheck “Alpha”

Images Loaded

I loaded the images into iTunes connect. It complained about one of the images, but logging out and logging back in let me put the last image into place.

Now What?

Next step, I need a website. While figuring out how to get a starter webpage up quickly that doesn’t totally stink, Freddy A. Montas mentioned LaunchKit. Glancing at a related TechCrunch article, it seems like LaunchKit might take care of what I need and maybe even the App Store screenshots I just did. So, all of the above might not be needed in the future. That’s OK. I learned a lot and that won’t be my last release into the App Store.

Good luck with your app submission and marketing adventures!

Disclosure: I work for CARFAX as an iOS Software Developer.

Update April 2019: Apple Screenshot specifications require an upload of 6.5-inch screenshots. That means the iPhone XS Max. However, Screenshot Maker Pro does not support iPhone XS Max. This will not do. I am hoping that reading Save time and increase your apps conversion rate serves well.

RxSwift Moved Swiftly from 1.9 to 2.1

RxSwift 2.1.0 is out! Congrats to kzaher and all the members.

Since things moved fast over the winter holidays in RxSwift, you might see some changes that happened between 2.0.0-beta.4 and 2.0.0 that interest you if you haven’t switched yet. When moving from the latest RxSwift beta to 2.0.0, the 2.0.0-rc.0’s Deprecated section of the Change Log may answer some compilation issues you face.

Straightforward changes were needed for my work. For example, I needed to stick Observable in front of create. As covered in the Change Log:

Deprecates free functions in favor of Observable factory methods

An interesting one involves Variable:

Deprecates Variable implementing ObservableType in favor of asObservable()

Looking at GitHubSignup “UsingVanillaObservables > 1″ and “UsingDriver > 2″ in the RxExample code, I see the answer to my questions and so much more. There is an emphasis on using Driver as opposed to Variable objects. Although, a deep dive into Driver is a whole other topic.

In regards to 2.1, the changes from 2.0 to 2.1 are minimal and had no impact on my work.

Enjoy the new stuff!

When and Why Did I Start Meditating?

Why does anyone do what they do? Curiosity is one driving force. Another force comes from beliefs. Beliefs form thoughts which inspire action.

Among other beliefs shared with me while growing up, I believed in actualizing my potential. Among other influences, this was impressed upon me by my parents and a special athletic group known as Sokol.

Formally known as the American Sokol Organization, I belonged to this gymnastics group for almost all of my life as a child. Sokol has the philosophy of a “A Sound Mind in a Sound Body.” Beyond the philosophy, it felt like a good idea. I never regretted attempting to actualize my potential.

While pursuing this continuous quest, I noticed that martial arts had a similar flavor of one being the best they can be. On top of that, the martial artists were doing something new and curious to me. They were meditating!



Based on my Sokol training, I knew that a healthy body wasn’t enough. Yet, how can one strengthen and actualize the mind? Being a kid and seeing meditating also happening in Star Wars, this meditation thing had to be explored! I went to the library and learned what I could.

To make a long story short, I was exposed to the basic techniques and many beliefs that came with my introduction to meditation. I meditated for many years. Over time, I shed myself of the beliefs which did not serve well. For awhile, I even stopped meditating since I wasn’t certain meditation was backed by science.

Just a few years ago, I came across some scientific proof that meditation yields a better brain. In short, increased focus and the ability to respond as opposed to blindly reacting to my emotions was something I gained. Now there was scientific proof from multiple sources too.

The question that remained for me was whether or not I was doing meditation well. I learned from some meditation iPhone apps that this is a common question. The simple answer is that one should just try their best and yet not focus “too hard.” What is especially important is to make meditation into a daily habit.

From what I learned from Nir Eyal and his excellent Hooked book, forming a habit is a well understood thing. For me, I came to understand that no matter what I will meditate daily even if it is for two minutes no matter how silly it felt. The daily repetition helped make it stick even in my most busy times.

So, the journey continues. As a thank you to others who have helped me on this path of self-actualization, I pay it forward. I share what I have learned with others.

Good luck with your own quest for excellence!



Swift structs, closures and Memory Leaks

Using structs and registering closures with a framework? Did you know closures are reference types?

If your closure is registered with a class from a framework and the closure is closing over self then you have a strong reference cycle memory issue. For example, let’s say we have a struct which has an RxSwift class Variable<String> member called someVariable.

When you give the subscribeNext the closure, it will store that closure into the framework. In other words, it has a reference to the closure. If you are referring to self in that closure, you have a strong reference cycle. The struct has a Variable which has a closure that has a reference back to the struct.

Can we just make the self reference a weak reference? No. Not if it’s a struct.

If it’s a class, we can do the following:

Note that we are using class and [weak self] now. We also took away the mutating from before the function.

That solves the memory issue! Thanks goes to some helpful humans which include Darren and Marc Khadpe in this Stackoverflow post.

Update: For an example such as this, Carlos García rightfully pointed out that using [unowned self] would be better. It’s faster and more. Carlos pointed out this article: How Swift Implements Unowned and Weak References and a related Twitter thread.

If you are going to use unowned, you will want to know when your app can crash when using it.  “Weak, Strong, Unowned, Oh My!” – A Guide to References in Swift is a good guide for when to use weak, unowned, and the default strong references.

Swift Protocols With Associated Types – PATs

What first led me into understanding Protocols With Associated Types (PATs)? Answer: RxSwift. It’s an awesome FRP framework for Swift.

What led me to the protocol compilation error “..can only be used as a generic constraint” which looks like this?

1PAT with compiler error

(Source: Alexis Gallagher – Protocols with Associated Types – 1:24)

Answer: Applying BDD (Behavior-Driven Development) to our Protocol Oriented MVVM RxSwift empowered code and using dependency injection.

We were going to use structs and protocols wherever we could. However, we had to back off some. Thanks to Alexis Gallagher, it’s clear now why we ran into the same problem that he presented in his video presentation, Protocols with Associated Types and how they got that way (maybe). Here’s a problem example he shows:

2PAT single variable declaration

(Same source: 2:47)

This great presentation was part of the 2015 Functional Swift Conference. The Protocols with Associated Types, and How They Got That Way slides are available. However, I highly recommend listening to the whole presentation. Since it’s 56 minutes long, this blog post links to certain key parts of it with associated snapshot images just to give you a taste of what is in there.

From this presentation, there are some crucial key takeaways:

  • Can’t use dynamic dispatch with PATs
  • typealias can do two very different things
  • There are workarounds if you need to do dynamic dispatch

Can’t Use Dynamic Dispatch With PATs

The compilation error “..can only be used as a generic constraint” described above shows how PATs are unique and different from plain old Protocols. The following dives into the ramifications of this situation:

3No Dynamic dispatch

(Same source: 6:54)

PATs are their own thing. As Alexis G. says, call them PATs and recognize how they are different.

typealias Can Do Two Very Different Things

4typealias two different uses

(Same source: 11:39)

As specified in the Swift Language Reference on Declarations, you can use typealias to:

  • Create a name for a type. See the “Type Alias Declaration” section.
  • Require something that conforms to a PAT, to specify a type. See the “Protocol Associated Type Declaration” section

Slide 18 of his presentation has a good example of showing typealias being used in a PAT.

There Are Workarounds If You need to do Dynamic Dispatch


(Same source: 39:08)

Workarounds are:

  • Enums
  • Type Erasure

The future looks bright if they add Existentials to the language. There is a Stackoverflow post about the generic concept an Existential Type.


Until they add Existential Types to the Swift language, we should fully understand PATs and how to use other parts of the Swift language to accomplish what we want.

As an aside: If you got this far, you really may want to watch the whole presentation on youtube. This blog post was made to just catch some of the interesting bits for later referral. Enjoy!

RxSwift Driver – What is it?

Curiosity is a powerful thing. When I saw this RxSwift Driver being discussed on RxSwift Slack and read the helpful RxSwift GitHub issue “Need better explanation / examples for Driver” submitted by Florent Pillet, it seemed helpful to capture what I saw.

As Carlos García shared on the GitHub issue:

One should think of the following:

as the same as:

Krunoslav Zaher aka kzaher on the RxSwift slack community said that it is a combination of: “main thread + shared subscriptions + no errors.” He goes on to say that shareReplay(1) is a shared subscriptions example. Carlos adds there are several examples in RxExample.

kzaher sums it all up nicely by sharing:

Yeah, it’s just a tiny builder/dsl for Observables. I think this should help me and others a lot with ensuring you can safely bind values to UI.

Using Driver is optional, but it helps the compiler catch things and will help emphasize things that might have been missed. As kzaher put it:

..and warn me when I’ve forgot to handle unexpected errors, or binding from background thread or doing something I should have when dealing with UI applications.

You may want to keep an eye on the RxSwift documentation as it grows and develops over time. Specifically, this Units document. Driver sounds exciting and I look forward to trying it in-depth in the near future!

Jan 2, 2016 Update: The Units document has been updated and much more has been added to it. Good stuff!