No, I’m not talking about that one…entirely.
I thought it would be worth pointing out—and thanking—Phil Schiller for the changes since he’s taken over the App Store back at the end of 2015. Plus, he also went to Boston College. People who went there are pretty smart I’ve heard.
With that, here’s a list starting from June 2016 through June 2017. Not mentioned in the formal announcements are the much faster review times, letting developers use the same Apple ID across iTunes Connect organizations, and giving developers more control over resetting reviews. The breakdown includes commentary on what we especially liked and what we hope to see continue to improve.
All in all, these are amazing updates in a relatively short period of time. Congrats to Phil and the entire, hard-working App Store team!
Rewritten App Review Guidelines with more context, including guidance for Mac apps. While these can be improved further, it showed empathy to regular complaints on ambiguity from the developer community.
Improvements for App Store optimization and analytics data, such as impressions. Developers had zero understanding of their App Store conversion rates before this update.
Only one size of screenshots required per device family. If you localize your app, this change helped considerably.
A focus from Apple on removing abandoned apps, which reflect poorly on the developer community. Also, an attempt from Apple to deal with keyword stuffing in App Store titles. It was a nice balance of not 100% closing off ASO best practices.
Subscriptions opened up beyond just content-driven apps, extended trials became available, and the 85/15 revenue split in year two for subscription apps. All welcomed changes. In our experience at Savvy Apps though, Apple is still overly restrictive about auto-renewing subscriptions specifically. It seems hard to get that revenue model approved for new apps that are not content or media-specific. They don’t yet show “ongoing value,” which is obviously hard to show for a brand new app. There was also an update for better reporting of subscriptions on September 13, 2016.
Certificates are still painful as a whole, especially when doing 2-3 different builds per app (production, staging, development). That may change with the TestFlight updates from April 2017. Taking push certificates out of the equation though is helping. Our development team members love this change in particular.
September 28, 2016 - Search Ads
Search Ads are really nice for new apps in particular because it takes some time to begin to rank for relevant terms. Developers can also start to compete with those companies and apps that dominate organic search results.
When marketing your app before this date, in-app purchases were always problematic. This change ensured you can give key contacts a way to explore premium features and content.
While there are some great resources available for iOS design—including our own iOS Sketch Wireframe Kit and iOS Sketch App Icon Template—it’s nice to see Apple getting involved. A big win for Sketch as well, since Apple offers their resources both for it and Photoshop.
If you can’t beat them, join them. Developers wanted to drive ratings and reviews for their apps. Apple wasn’t a fan of third-party, in-app rating options, so they rolled their own solution. We jumped on it but would like to see the ability to trigger the ratings prompt based on actions and behavior. A straight up app launch count, as it is currently implemented, could lead to negative reviews.
Responding to Customer Reviews
Responding to reviews really was a must-have. Other platforms had it and Apple was behind the curve. It’s an important change of policy. We also are glad that Apple notifies users when a developer response is made.
We previously had a fairly extensive TestFlight setup for multiple builds that we are hoping to streamline. Allowing testers to have multiple TestFlight builds is critical, keeping them on a build once it goes live makes tester lives easier, and the update to groups brings significant efficiency.
Like the App Store impression information, this update lets developers get vital information. Once you know what particular channels have the largest impact on downloads, you can then focus on similar outlets or better try to optimize lower-performing sources.
I ran down the changes in my post on 11 considerations for updating your app for iOS 11. The App Store redesign hopefully will help with better discovery for non-game apps, highlight many more apps with “Apps of the Day,” and drive more downloads and in-app purchases with the revamped product page.
You might have guessed that I’m not breaking up with Slack. We’ve been using Slack and other tools like it since the early days of Savvy Apps back in 2009. Through the years, we’ve continued to both try new tools and end of life others. Whether it was Unfuddle and Campfire in the older days or Trello and Slack in 2016, we’ve constantly looked at each tool in terms of what we want them to do for us. We’ve had regular conversations with our team about how—and how not—we should use each of these tools. The reason? We never want any of them to run our day.
Being Unproductive is Not Slack’s Fault
Whether it’s Slack, HipChat, Trello, JIRA, Dropbox, GitHub, email, or any number of other tools, most people and organizations let the tools they use dictate how they’re supposed to work. They haven’t taken the time to think how best to use these tools or how they fit into their workflow. As a team, they then don’t have a shared perspective on what these tools are for and how they should be used. With each person then using these tools how they want, the results are frustration, distraction, becoming unproductive, and yes, even people blaming and quitting these tools.
Consider for a moment the introduction of email though. It was a much bigger shift for the workplace than Slack ever has been. Email was revolutionary. Slack is evolutionary. Slack had immediate predecessors ranging from Campfire, HipChat, and even IRC. Yet email, while not without problems if unbridled, is now embraced universally. Like email, Slack and comparable tools simply need some best practices and guidelines to be used the right way. They don’t, however, need to be quit.
Define How Slack Should be Used
Slack and other real-time tools should not be considered the sole communication methods for you or your organization. They are built to be real time, meaning that they are beneficial to discuss items that are relevant now. The biggest mistake made is to use them to discuss anything and everything under the sun. Often Slack is used to discuss future tasks, topics that require extensive thought, sensitive items, or to get feedback from people that may not even be available for conversation.
Real-time tools like Slack should not become replacements for documents, files, task & ticket systems, and even email. They should also not become replacements for other real-time ways of communicating, including in-person discussions, voice, or video calls.
Slack Equals Now, Not Later
At Savvy Apps, we rely on Slack for work that is in progress. If someone is working on a bug or feature for example, they discuss that specific work in a channel. We discourage using Slack to address future work or anything else that is not being worked on in that exact moment. These kinds of exchanges can go onto a Trello card , Pivotal Tracker ticket, Quip document, or comparable places. You can obviously insert your relevant tool, these are just the ones we use.
When future items are discussed in Slack, important context for that task gets lost in the channel instead of its permanent home (i.e., a card or ticket). By keeping all conversation in a single destination, when that work then comes into focus, everyone has the right context and no one has to go searching for previous conversations.
Keep Conversations in Channels
Almost all conversations should occur in a channel. Keeping conversations in channels ensures that all conversations are indexed and searchable. In other words, full context is available and not trapped between team members via direct messages (DMs). For example, a designer and developer, might talk about the nuances of an interaction. If that happens in DMs instead of a channel, a product manager would never know about it. Another developer who might step in to help would also lose that context.
An added benefit to this approach is that it greatly reduces the burden of direct messages. DMs can become overwhelming, especially because people feel they must be responded to, often immediately. By instead mentioning someone in a channel, they can get back to it when they have the opportunity to do so.
Limit Channels as Much as Possible
Each project we’re working on at Savvy Apps is a channel. We also have a global channel we call our lounge and channels for each discipline (e.g., design or DevOps). The second type of channel often becomes more focused on sharing links and resources relevant to that team. Anyone can join any channel but channels and private groups can only be provisioned by team admins or owners.
This approach might seem overly limiting but it ensures the number of channels don’t get out of control. If someone needs a channel, they can ping a team admin and ask that person to create it. In general though, our philosophy is that less channels are better. It reduces splitting conversations. As an example, we had a separate user experience and visual design channel in the past but decided to collapse them to encourage more interaction and discussion amongst team members.
Keep Slack at Work and Reduce Notifications
Do Not Disturb for Slack was a welcome addition. How about one step further though? Don’t even install Slack on your mobile device. Slack doesn’t need to follow you everywhere. If you use it for work in particular, keep it where you do work, on your desktop, laptop, or tablet.
Be selective with how you’ve enabled notifications as well. We use to encourage people to add their name to their Slack settings to trigger a notification. We’ve since changed that to rely solely on a mention to send a notification. This way someone’s name can be mentioned without worrying it would draw their attention to it (and also avoid having to write something like “K3n”).
When to Take Conversation Outside of Slack
Our general guideline is that if a topic is taking more then ten minutes to discuss in Slack, pop into a Hangout or walk over to someone’s desk. It doesn’t make sense to spend all day pecking away at a keyboard, especially when others may be getting confused or frustrated.
There are also times where it’s just best to stop discussing a topic either in Slack or otherwise. Take a step back and write up a document to clarify your thoughts, how a feature is supposed to work, or the ultimate outcome you’re attempting to accomplish. Then let others digest what you written and schedule some time to talk through it with them. As noted above, remember that Slack should not be the final resting place for important takeaways, action items, or next steps.
You Don’t Need to be a Part of 57 Slack Teams
Yes, there’s a Slack team for almost anything you can imagine. If you keep joining them, you’ll continue to have a higher and higher demand on your time. Whether it’s for conferences, industry, beta testing, friends, or your local coffee shop, joining more and more Slack teams just doesn’t make sense.
I decided a long time ago I would use Slack for one purpose and one purpose only, which is to communicate with my team. Historically, I’ve use Twitter at conferences or to chat with industry peers, SMS and iMessage with friends and family, email to send beta feedback, and other tools. These workflows were not broken before and thus don’t need replacements. I’m not saying you need to only join one Slack team, just be selective.
The Future of Slack
Slack realizes that messaging is not the final frontier for communication in the workplace. They have continued to invest into what they call “posts” although we prefer a formal document-based tool like Quip. They also recently rolled out audio calls in beta.
We’ve been pretty happy with the Hangouts integration for video and they have a number of other video and screen sharing integrations in their directory. We’re most excited about them continuing to integrate their Screenhero acquisition into a native video and screen sharing experience. The one-click option for these tools will further eliminate the hassles and frustrations many have with text-only messaging.
Those alone will not be the solution though. Take the time to think about how you want to use Slack or your comparable solution, along with all the other tools available to your team. You’ll be pleasantly surprised when there’s a common ground for how to think about and use these tools. By establishing these guidelines for yourself and your team, you’ll feel much more fulfilled, less distracted, and ensure that no tool runs your day.
I’m a big proponent on focusing on doing good work and letting the rest fall into place. That doesn’t mean that I never plan, I just often focus more on executing at my standard of quality versus the end result. James Clear takes that a step further in his Forget About Setting Goals. Focus on This Instead,
What I’m starting to realize, however, is that when it comes to actually getting things done and making progress in the areas that are important to you, there is a much better way to do things.
It all comes down to the difference between goals and systems.
He provides some compelling arguments for why goals can actually be counter-productive to success, outlining the strengths of focusing on systems. It’s a worthwhile read.
Benedict Evan’s “Cloudy” take on WWDC has dovetailed with a number of thoughts I’ve had over the last few months:
I’ve described this before by saying that Apple is moving innovation down the stack into hardware/software integration, where it’s hard for Google to follow, and Google is moving innovation up the stack into cloud-based AI & machine learning services, where it’s hard for Apple to follow. This isn’t a tactical ‘this’ll screw those guys’ approach – it reflects the fundamental characters of the two companies. Google thinks about improving UX by reducing page load times, Apple thinks about UX by making it easier to scroll that page.
In particular, this excerpt reminded me of Fred Wilson’s recent comments about Apple not being a “top three” technology company by 2020 because they don’t get the cloud. Over the last couple of years, it has been arguable that Google is getting better at what Apple does faster than Apple is with Google’s core competencies. Whether it’s user experience, design, or even a more platform-centric approach, Google has advanced those fairly quickly compared to Apple’s mastering of the cloud.
So, yes it was a year of Apple having the cloud—including what Benedict calls the “personal cloud”—underpin a number of their key initiatives. But with Google getting better at some of Apple’s strengths, will Apple’s “dumb cloud” approach be able to compete with the likes of Google Now?
I would guess that many consumers would still choose using SMS or taking phone calls from their Mac—features powered by OS X Yosemite and iOS 8—over being told when to leave for an appointment. Clearly each of those kinds of features appeal to a specific demographic but Apple continues to cater more directly to everyday convenience where Google’s AI and machine learning are attempting to solve bigger and more complex problems. Obviously Google Now is just one example but self-driving cars and drones also come to mind.
Put another way, Apple continues to optimize for the relatively near term. Each year they make consumers lives just a little bit better. What they bring to the market may not appear as lofty as Google’s future initiatives but as John Gruber notes, Apple knows how to ship. These aren’t concepts, they’re products that scale to the mass market.
Of course, Apple has their own future-focused, mind-boggling roadmap, which is what has allowed them to launch market-transforming products like the iPhone or iPad. Still, I’ve wondered if Apple is not focused on the future enough. The corollary may be more pressing for Google: optimizing too much for the future will continue to reduce the impact they can have on the present. Apple may not have self-driving, concept cars but there’s no company that can compete right now with their ability to deliver incremental, everyday convenience to the mass market each and every year.
Running your own business can be frightening. For many businesses, there’s a natural ebb and flow to sales or even some sort of seasonality. In the consulting world, the fear of no new customers or losing existing customers can push a business owner to take on the wrong kind of business or make bad decisions.
For a number of year years now—thanks to my father-in-law—I’ve appreciated Alan Weis’ perspectives on consulting. His recent post on this topic really resonated with me:
Some potential business is too small, too remote, too laborious, too demanding, too ridiculous. Some of it is unethical or repulsive. Eschew it.
Pursue that business which you are great at and love doing, provided by your ideal buyers. It’s as simple as that.
One might be tempted to think that being able to “choose a customer” is only applicable when business is booming. It’s that type of thinking that can get you into trouble.
There’s an opportunity cost to taking on the wrong customer. The biggest one being that when the right customer comes along, there’s a higher likelihood that you won’t be available to work with them.
My experience also dictates that the “wrong” customer is usually wrong for three reasons, not just one. For example, it’s likely not just about the customer being demanding. It’s that the customer is demanding, the budget too small, and the timeline too tight.
At savvy apps, we look at potential customers through three lenses:
- Do we believe in and like the idea?
Is this app something we would use? Is it focused enough? Can it continue to evolve?
- Do we believe in the people and the team?
Are they proven? Do they have key advisors and industry contacts? Would we enjoy working with them?
- What do we see as the long-term potential for the relationship?
What happens after v1.0 ships? Will this customer make referrals? Will there be new work outside of this app?
Even during slow times, we’ve turned down business that did not align with one of these kinds of tests. While turning down money is a difficult choice, I know that the right customer will motivate us to produce award-winning work and keep our attrition extremely low.