Under the Radar

00:00:00 ◼   ► Welcome to Under the Radar, a show about independent iOS app development.

00:00:04 ◼   ► I'm Mark Orment.

00:00:05 ◼   ► And I'm David Smith.

00:00:06 ◼   ► Under the Radar is never longer than 30 minutes, so let's get started.

00:00:09 ◼   ► So today I wanted to talk about, kind of related to a recent discussion about trying to get,

00:00:14 ◼   ► you know, watch podcast playback, and I did a blog post this week basically saying, like,

00:00:18 ◼   ► here's what we need to do this.

00:00:21 ◼   ► And I kind of wanted to talk about the process of trying to affect change with Apple and

00:00:27 ◼   ► their products and their stores and everything else.

00:00:30 ◼   ► And this takes a lot of different forms.

00:00:32 ◼   ► I think the first thing I wanted to talk about is how to know what you can and can't change.

00:00:40 ◼   ► If you're going to try to get something done at Apple or try to get a bug fixed or try

00:00:44 ◼   ► to get a feature done or try to get something, some policy changed, it helps to know the

00:00:49 ◼   ► company well enough to know basically what fights aren't worth fighting and, you know,

00:00:54 ◼   ► what's not worth your effort and what is.

00:00:57 ◼   ► If you want to, like, get bugs fixed or, like, get API changes to some degree, that stuff

00:01:03 ◼   ► is usually possible.

00:01:04 ◼   ► Those are fights worth fighting.

00:01:06 ◼   ► A lot of people try to get unfair or arguable App Store rejections overturned.

00:01:13 ◼   ► I think it is worth challenging unfair or arguable App Store rejections sometimes.

00:01:20 ◼   ► Unfair, to me, means that the rules were not applied correctly or maybe consistently with

00:01:26 ◼   ► other apps.

00:01:27 ◼   ► Unfair does not mean you disagree with the rules.

00:01:30 ◼   ► That's a different situation.

00:01:32 ◼   ► So if you've been rejected for some way that you think is actually unfair, like the

00:01:35 ◼   ► rules were not applied correctly, that is usually worth, you know, filing the appeal.

00:01:40 ◼   ► And if that doesn't work, then maybe going public with it.

00:01:43 ◼   ► As for arguable App Store rejections, that's very broad.

00:01:48 ◼   ► That could be a lot of things.

00:01:49 ◼   ► If you keep hitting rules that are arguable, maybe you should rethink what kind of apps

00:01:55 ◼   ► you're trying to make because generally I recommend that you don't build a business

00:02:00 ◼   ► or attempt to build a business on living on the edge of a rule.

00:02:04 ◼   ► You know, if you stay away from the edges of the rules or the vagaries or the exact

00:02:08 ◼   ► interpretations of certain rules, you're generally going to be happier and it's going

00:02:11 ◼   ► to be easier to do business both, you know, immediately and going forward.

00:02:15 ◼   ► So, those are generally, the things that generally you can affect, bugs, APIs, and, you know,

00:02:23 ◼   ► bad App Store rejections.

00:02:25 ◼   ► And, you know, what you can change can take a number of different forms.

00:02:28 ◼   ► You know, you can obviously, you know, with App Store rejections you can do the private

00:02:31 ◼   ► appeal which I definitely recommend you do first.

00:02:34 ◼   ► Those appeals often work.

00:02:37 ◼   ► I've heard a lot of stories from friends and other developers who have appealed things

00:02:42 ◼   ► and they do get overturned.

00:02:43 ◼   ► What's your experience with that?

00:02:44 ◼   ► I have many experiences with that and in general I would say that is, I've had, usually

00:02:50 ◼   ► we can come to some understanding.

00:02:53 ◼   ► Like often the sort of, A, I think that Apple appreciates the working it through with them

00:03:02 ◼   ► first in that sense of, I've dealt with all kinds, a variety of rejections for a variety

00:03:07 ◼   ► of reasons and work, you know, I think the impression I've gotten is that you get farther

00:03:13 ◼   ► by not running to the press, not trying to make a big fuss.

00:03:17 ◼   ► Like maybe that is the final straw like that you do down the road but that initially you

00:03:23 ◼   ► work with them and you work with them patiently and, you know, with politeness and respect

00:03:28 ◼   ► and you work through it because typically they're coming at, you know, it's like

00:03:32 ◼   ► the issue, unless you're just doing something wild and off the reservation, like usually

00:03:37 ◼   ► there is some sticking point that they're stuck on that you have to work out a way to

00:03:41 ◼   ► work around.

00:03:43 ◼   ► There may be a small change that you can make to your app that will affect that change and

00:03:48 ◼   ► if you handle that in a respectful way, in my experience, the appeal process and working

00:03:54 ◼   ► those channels directly will often get you somewhere.

00:03:58 ◼   ► Sometimes it may not be exactly where you would like to be, sometimes you'll end up

00:04:02 ◼   ► having to make changes to your app that may limit its functionality or make you feel like

00:04:07 ◼   ► you've lost a competitive edge or something but by and large that process does work and

00:04:15 ◼   ► while it can be frustrating in the moment and I've certainly been very emotional in

00:04:20 ◼   ► the moment, you know, when I work on something for months and you submit it and then it gets

00:04:27 ◼   ► rejected for a reason that you don't agree with, like that's a very emotional thing

00:04:30 ◼   ► but it does ultimately work through and just being respectful, making sure you're out

00:04:36 ◼   ► of control, making sure you're understanding the subtext around what they're saying I

00:04:41 ◼   ► think is something that I've found to also be helpful that often they're saying one

00:04:45 ◼   ► thing which is correct but it's because of something else, like there's an underlying

00:04:50 ◼   ► reason that you're trying to find and the better you can try to understand that or ask

00:04:55 ◼   ► probing questions around that, the better you're able to make a change because usually

00:04:59 ◼   ► what I've ended up happening is it's unlikely that they'll be like, "Oh, actually

00:05:04 ◼   ► we made a mistake, you're fine now." Maybe they will, maybe they won't. In my experience

00:05:08 ◼   ► usually it's a more likely scenario is, you know, here's this small change that I can

00:05:15 ◼   ► say, like, if I did this, would it be okay then? And they often say, "Well, we can't

00:05:19 ◼   ► pre-approve it but that's heading in the right direction." And then I make a change,

00:05:23 ◼   ► I resubmit and everything's fine. But it does work. Like, I've gone through that

00:05:27 ◼   ► process enough times and gotten apps that were rejected, ultimately approved, often

00:05:33 ◼   ► with relatively minor changes. So it does work and it's something that I would encourage

00:05:37 ◼   ► you to do and it's definitely the place to start. Thankfully, I've very rarely, if

00:05:42 ◼   ► ever, had to try to make a big fuss to get something to happen because you're going

00:05:48 ◼   ► all in at that point. It's either going to work or it doesn't. And even if it does

00:05:53 ◼   ► work, you're putting your app in kind of an awkward situation for its future going

00:05:57 ◼   ► forward. If it was ultimately accepted but not under the best circumstances, what does

00:06:04 ◼   ► that mean in six months when you submit a big update and you're kind of doubling down

00:06:08 ◼   ► on the features that were questionable to start with? So that's certainly my experience.

00:06:13 ◼   ► And it works and it's an encouraging process that's gotten a lot better than back, whatever,

00:06:19 ◼   ► eight years ago when things were a much more—like, I don't think on Apple's side they had

00:06:26 ◼   ► quite dialed in their process there to the degree they have now.

00:06:30 ◼   ► That's generous.

00:06:31 ◼   ► Yeah, it works better now.

00:06:33 ◼   ► Yeah, it's way better now. All right, so those are kind of the things that you can

00:06:38 ◼   ► affect change with. There's also a lot of things that you can't really affect change

00:06:43 ◼   ► and that your effort is probably wasted and that might even annoy Apple if you do it.

00:06:47 ◼   ► And this includes things like trying to get major app store policies or business rules

00:06:54 ◼   ► changed or get exceptions for yourself. This is things like getting around the 30% cut

00:06:58 ◼   ► for in-app purchases or subscriptions or things like that. This also includes campaigning

00:07:04 ◼   ► for major technical changes that are very unlikely to do, so things like allowing all

00:07:09 ◼   ► iOS apps to run in the background indefinitely. If you just want to have a persistent daemon

00:07:13 ◼   ► running on iOS, that's never going to happen. They're never going to allow that.

00:07:16 ◼   ► Also, things that combine both of these, like both app store policy and major technical

00:07:21 ◼   ► things like allowing sideloading of iOS apps, that's probably never going to happen either.

00:07:27 ◼   ► I respect people who try to make that case to Apple, but I think it's futile. I don't

00:07:32 ◼   ► think it's ever going to happen. And also, kind of obvious things like anything that

00:07:37 ◼   ► could be potentially abused, like even if you have good intentions on something you

00:07:42 ◼   ► want to be able to do, you have to think about what could a bad actor do with that same ability.

00:07:48 ◼   ► So anything that could be abused for privacy violations is a big one. So things like access

00:07:52 ◼   ► to restricted hardware, things like face ID, touch ID, secure enclave stuff, access to

00:08:00 ◼   ► the restricted privacy sensitive APIs like location or microphone without prompting the

00:08:05 ◼   ► user, stuff like that. If you need those things, you're going to have a hard time. That's

00:08:10 ◼   ► probably not a great way to spend any amount of effort trying to affect change at Apple.

00:08:16 ◼   ► And also, there's a big one that's kind of sad, but it's reality. And that is if

00:08:22 ◼   ► you're trying to get bug fixes or API changes for either very old or very low priority APIs

00:08:31 ◼   ► or platforms. And so this would include low priority platforms in general. I would say

00:08:37 ◼   ► things like TDOS is pretty low priority. I would say unfortunately most of Mac OS is

00:08:41 ◼   ► pretty low priority. So if you want some API enhanced on a low priority platform, you're

00:08:48 ◼   ► going to have a hard time doing it. Even a bug fix. If it's not a really critical bug,

00:08:53 ◼   ► you might have a hard time even getting anybody to care about that or to have time to work

00:08:57 ◼   ► on it. Because even if you make a great case for some kind of change like this, if nobody's

00:09:03 ◼   ► working on that thing, there's no one to fix it. It's not going to happen. A lot

00:09:08 ◼   ► of Apple projects will go either completely unstaffed or staffed by one person who also

00:09:16 ◼   ► worked on 17 other things for years. Who maintains a dress book? It's probably one person who

00:09:24 ◼   ► also maintains six other frameworks. And even when you have a small staff on a project,

00:09:30 ◼   ► they might not have time to do your bug or your enhancement. Because every year when

00:09:35 ◼   ► Apple does big new headlining features that they market to customers or they have new

00:09:41 ◼   ► hardware that things need to take advantage of or be adopted for, all those one person

00:09:47 ◼   ► or small teams that are working on old apps or less high priority things, they have to

00:09:56 ◼   ► adopt those marketing features first. Those will always take priority over old enhancements

00:10:01 ◼   ► or bug fixes they also want to do. So for a lot of projects at Apple, there's literally

00:10:07 ◼   ► not time for much of anything else. So if you file some bug with iWork, iWork is a great

00:10:14 ◼   ► example because it has a staff. iWork is staffed. But iWork is involved in so many marketing

00:10:22 ◼   ► features every year that it has to adopt or that it has to make sure it works with. So

00:10:27 ◼   ► any changes to iOS, changes to the multitasking, the file picking, document handling, changes

00:10:32 ◼   ► to iCloud, collaboration, sharing. iWork is involved in all sorts of crazy stuff. And

00:10:38 ◼   ► so if you have a feature request or some kind of minor bug in iWork, that's going to take

00:10:45 ◼   ► way lower priority than all the crazy marketing stuff they have to do every year just to keep

00:10:50 ◼   ► up with Apple's own stuff. So there's a lot of projects at Apple for which you can file

00:10:55 ◼   ► bugs or you can write a nice blog post saying that you wish this obscure bug would be fixed

00:11:01 ◼   ► or that you wish this API was different. But if it's a low priority or old API or project

00:11:07 ◼   ► or if its staff is way too busy doing other stuff, you're going to have a really hard

00:11:11 ◼   ► time with that.

00:11:12 ◼   ► >> And to that end, I think also it's hard for us to have a sense of what the future

00:11:19 ◼   ► is going to hold. We're at a disadvantage to Apple in the regard that they know what

00:11:27 ◼   ► next year's release is going to look like and have a good idea probably of what the

00:11:31 ◼   ► next release after that is going to look like. And so if you're filing bugs against frameworks

00:11:35 ◼   ► or things that Apple knows they have different plans for in the future, then it's going

00:11:42 ◼   ► to become even harder likely for your bug or your issue to be addressed. And maybe in

00:11:48 ◼   ► the best case it will be rolled into the changes they're making or if they're replacing the

00:11:51 ◼   ► framework with something better. Those types of things may come into play, but it's the

00:11:56 ◼   ► awkward thing too. All we see is the end results and we can't know what's coming in nine

00:12:03 ◼   ► months whereas Apple does. And so it's entirely possible that a bug comes in for a framework

00:12:07 ◼   ► and they're like, "Yeah, we're not going to fix that because in ten months that framework

00:12:13 ◼   ► is going away or it's going to be replaced with something better. They're rather going

00:12:16 ◼   ► to put their engineering effort into that." And so that can often, if we file a bug, we

00:12:22 ◼   ► can do all the right things. If you have an example project, show how to reproduce it,

00:12:27 ◼   ► it may never get fixed. And the reason why it may never get fixed could be any of the

00:12:31 ◼   ► things you were just talking about in terms of staffing. It could just be a question of

00:12:34 ◼   ► priorities or the future. It's impossible to know exactly why it happened and that can

00:12:39 ◼   ► sometimes be frustrating, but that's just the reality I think.

00:12:42 ◼   ► We are sponsored this week by Blue Apron, the number one recipe delivery service with

00:12:46 ◼   ► the freshest ingredients. Blue Apron's mission is to make incredible home cooking accessible

00:12:51 ◼   ► to everyone and support a more sustainable food system. They set the highest standards

00:12:55 ◼   ► for ingredients and they're building a community of home chefs. For less than ten dollars per

00:12:59 ◼   ► meal, Blue Apron delivers seasonal recipes along with fresh, high quality ingredients

00:13:04 ◼   ► to make delicious home cooked meals in forty minutes or less. See, our show's a little

00:13:08 ◼   ► bit shorter than that. It's pretty good.

00:13:09 ◼   ► Yeah.

00:13:10 ◼   ► Each meal comes with a step by step, easy to follow recipe card and pre-portioned ingredients

00:13:15 ◼   ► and they ship the exact amount of each ingredient that the recipe requires. So they are reducing

00:13:20 ◼   ► food waste in the process. And Blue Apron's freshness guarantee promises that every ingredient

00:13:25 ◼   ► arrives ready to cook or they will make it right. I personally have been a Blue Apron

00:13:29 ◼   ► customer with our family for, oh geez, I don't know, maybe two years now? It's been a while

00:13:34 ◼   ► now, even before they were sponsoring any of our shows. And we just love Blue Apron.

00:13:39 ◼   ► Their recipes are fantastic. We have really become better chefs as a result of having

00:13:45 ◼   ► Blue Apron. It is awesome. We've tried so many new foods, new cuisines, things we would

00:13:50 ◼   ► never even order in a restaurant that all of a sudden we're cooking. And then they're

00:13:54 ◼   ► delicious and now we go out and order those things in restaurants. It expands your horizons

00:13:59 ◼   ► for food and also it really does make you a better cook by just having so much more

00:14:03 ◼   ► experience. And on nights that we don't have Blue Apron, we make better things now.

00:14:08 ◼   ► So you can choose from a variety of new recipes each week or you can just let their team choose

00:14:12 ◼   ► for you and surprise you. You can cook meals like soy glazed pork and rice cakes with bok

00:14:17 ◼   ► choy and marinated green beans, skillet vegetable chili with cornmeal and cheddar drop biscuits

00:14:21 ◼   ► or garlic butter shrimp and corn with green bean salad and roasted purple tomatoes. There

00:14:26 ◼   ► is no weekly commitment so you only get deliveries when you want them. You can cancel them at

00:14:30 ◼   ► any time. You can skip some if you're going to be out of town or whatever. It doesn't

00:14:33 ◼   ► matter. So check out this week's menu and get three free meals with your first purchase

00:14:38 ◼   ► including free shipping by going to BlueApron.com/Radar. You will love how great it feels and tastes

00:14:46 ◼   ► to create incredible home cooked meals with Blue Apron. So get started today by going

00:14:49 ◼   ► to BlueApron.com/Radar. Thank you to Blue Apron for supporting this show. Blue Apron,

00:14:54 ◼   ► a better way to cook. After all the discussion before of what you can change and what you

00:15:00 ◼   ► can't change at Apple. Now I want to talk about how you actually, the best ways to affect

00:15:05 ◼   ► change at Apple. If you're going to be doing something that's actually changeable, how

00:15:09 ◼   ► do you do it? So first as we talked about a little bit earlier, you should start with

00:15:15 ◼   ► private methods first. So very first thing with any bug or enhancement is file a radar.

00:15:22 ◼   ► And this is a hard thing to do because the radar system is, it's almost punitive. Like

00:15:28 ◼   ► it really is almost abusive. Like in how much effort they want you to invest into filing

00:15:35 ◼   ► bug reports even down to things like making sample projects which they will almost always

00:15:39 ◼   ► request for almost anything even if it doesn't seem to need it to the point where I almost

00:15:43 ◼   ► think it's a delay tactic so they can just close more bugs and people don't do it. But

00:15:47 ◼   ► actually I don't almost think that. I do think that. But anyway, so file a radar first.

00:15:52 ◼   ► And the reason why is because radar is, it's Apple's bug reporting system and radar is

00:15:59 ◼   ► how Apple passes things around and prioritizes things internally. So if you later want to

00:16:06 ◼   ► write a blog post or email somebody in the company or bother somebody on Twitter who

00:16:11 ◼   ► works there or something, if you want to like escalate things further, it really helps to

00:16:16 ◼   ► have a radar number or series of numbers to point them to, to say look, this is what I'm

00:16:21 ◼   ► talking about. Because then if they actually take up your case and if they want to prioritize

00:16:28 ◼   ► something in the company or forward it to somebody else or get it to the right department

00:16:31 ◼   ► or try to convince somebody that they should be prioritized, they are going to do that

00:16:36 ◼   ► by passing around radar numbers to people. And so it really helps a lot if you have a

00:16:42 ◼   ► radar filed. I'm not always the best at this and usually when they ask for a sample

00:16:45 ◼   ► project I just get mad and just abandon it because I'm like I'm not going to waste

00:16:48 ◼   ► my time doing this. You know, you should fix this bug. But that is the most effective way

00:16:52 ◼   ► to do it. And that, you know, and so generally radar first and then keep things private first

00:17:00 ◼   ► if you can. So obviously with App Store appeals, you know, do the private appeal first before

00:17:04 ◼   ► you go public because most of the time you won't need to go public and that'll be nice.

00:17:08 ◼   ► When you have, when you do need to go public, it makes your case a little more defensible

00:17:13 ◼   ► to them internally if you can say, like if you basically tried to do it privately first.

00:17:19 ◼   ► You know, similar thing with like when you're reporting security vulnerabilities. I feel

00:17:22 ◼   ► like, I mean, I don't know much about that community, but I think it works in a similar

00:17:25 ◼   ► way where it's like you try the private method first and then if it doesn't work, then

00:17:30 ◼   ► you consider going public. Do you file radars and stuff for all your stuff or do you just

00:17:36 ◼   ► work it out yourself? How do you do that?

00:17:38 ◼   ► So I have a lot of I've found a great many radars over the years and they I think radars

00:17:44 ◼   ► tend to take different forms. Like some of my radars are just straight up bug reports.

00:17:50 ◼   ► Like I'm just saying I use this API in a way that it is documented that it should work

00:17:55 ◼   ► and it doesn't. And like those ones are relatively straightforward. And you know, like that's

00:18:00 ◼   ► I've that that's sort of the one side and the other side of the radars that I file tend

00:18:05 ◼   ► to be and I write them this way actually now I write them. They're almost just letters

00:18:10 ◼   ► like they're like like open letters to Apple saying or like guys closed letters to Apple

00:18:15 ◼   ► saying I believe it was called letters. Yeah, it's like here's this thing that you know,

00:18:20 ◼   ► like, hi, I'm I make these apps these are the and you know, this is something that I'd

00:18:25 ◼   ► like to be able to do with them at a current API can't do and I try and give as much

00:18:29 ◼   ► context and to sort of a try to flesh out the not just like what I want like not just

00:18:36 ◼   ► the like the technical like I wish this API would do XYZ but I try and provide like real

00:18:42 ◼   ► world situations and examples as to why you know, sometimes it's like in you know, he

00:18:47 ◼   ► even like here's a link to my app like here you can go see where this would fit in like

00:18:52 ◼   ► to try and build a case because as best I can understand and as you have I've several

00:18:57 ◼   ► and for several friends who work at Apple like I know a lot of people that the impression

00:19:00 ◼   ► I get is that like radar is this funny thing because we see this very kind of sort of terse

00:19:08 ◼   ► opaque thing on the outside where we put things in and then we'll either get you know flagged

00:19:12 ◼   ► as duplicate or nothing will happen at all for a long period of time but internally with

00:19:17 ◼   ► Apple you know, they have a whole other sort of discussions and threads and things that

00:19:25 ◼   ► are going on around you know, the radar that I filed that is happening internally and that

00:19:31 ◼   ► is the part that I'm trying to you know, provide as much information as I can to make

00:19:36 ◼   ► engineers within Apple's case or lives easy because the reality is with almost any change

00:19:41 ◼   ► that we want you know, there's like there's gonna probably gonna be someone at Apple who

00:19:45 ◼   ► thinks yeah, this is a good idea that might be other people who think this is not that's

00:19:49 ◼   ► not such a great idea and they're going to be having you know, it with any engineering

00:19:53 ◼   ► choice, there's usually you know, there's benefits and and you know, disadvantages and

00:19:58 ◼   ► you know, it can they may be thinking even in a broader sense because they have to not

00:20:02 ◼   ► just think of your specific case, but they need to think of the worst case of someone

00:20:06 ◼   ► else using this API. But they're having this discussion internally and like all I'm

00:20:11 ◼   ► really trying to do is if there is somebody who is going to be advocating for you know,

00:20:16 ◼   ► for the change that I want, I want to provide that person with all of the as much as I can

00:20:22 ◼   ► in terms of, you know, support and evidence to make that change happen. And so I just

00:20:27 ◼   ► write it right as much of these this as I can. And it can feel a bit funny in the sense

00:20:31 ◼   ► that, you know, the radar system is all about, you know, like, what was the expected result

00:20:36 ◼   ► and what did happen and like it gets used, obviously structured for technical reports.

00:20:41 ◼   ► But I find if I'm in filing an enhancement request, like that's what I do. I mean,

00:20:46 ◼   ► it's so hard to know how the degree to which like that is actually effective, but it's

00:20:50 ◼   ► just what I've over the years, what I've sort of gotten comfortable with doing, and

00:20:55 ◼   ► I've never heard anything bad about it, in terms of like, I've never had them closed

00:21:00 ◼   ► as like irrelevant or poorly or, you know, incomplete or written or something like that

00:21:04 ◼   ► does like, it seems like it's just a mechanism by which you can have private communication

00:21:09 ◼   ► with Apple, that someone inside of engineering will actually look at. And especially also,

00:21:17 ◼   ► I think in communication, like, if functionally the way you know, the developer relations

00:21:22 ◼   ► system works is, you know, we can file a radar, and then there's a collection of evangelists,

00:21:27 ◼   ► I mean, like all the essentially developer relations team is there to interact with developers

00:21:33 ◼   ► personally. So usually what I will end up doing is I'll file a radar, sort of put that

00:21:38 ◼   ► out there. And then depending on what the nature of the situation of the, you know,

00:21:43 ◼   ► enhancement request is, if I know the evangelist who would most closely fit that, I'll reach

00:21:48 ◼   ► out to them and I'll say, "Hey, here's this thing that I filed, you know, here's

00:21:52 ◼   ► the reason why I'm asking it, if you have any questions or things, you know, please

00:21:55 ◼   ► let me know." And, you know, sort of like in the same way that you may, you know, it's

00:21:59 ◼   ► like you submit your resume on the system, and then you also may follow up with an email

00:22:03 ◼   ► to a recruiter or something like, you know, you kind of you hit it in both ways, just

00:22:07 ◼   ► to make it that much more likely that someone's going to look at it. And they may disagree

00:22:10 ◼   ► with it, they may ignore it, they may not end up being effective, but at least someone

00:22:14 ◼   ► has looked at it and they've made an active decision to, you know, to not do it.

00:22:19 ◼   ► Also, the timing of when you file bugs or when you go public with things matters a lot

00:22:26 ◼   ► with Apple because, you know, Apple is a company full of human beings, and they're on a tight

00:22:30 ◼   ► schedule, and they all have, you know, more things on their plate than they have time

00:22:34 ◼   ► to do. But the good thing is we know their schedule. Their schedule matches the release

00:22:38 ◼   ► schedule of their products and their operating systems, so we know the schedule so we can

00:22:42 ◼   ► use it to our advantage. So, generally, like, if you file a bug or you, you know, bring

00:22:48 ◼   ► up a public thing at a time when they're really busy doing other stuff, it's going

00:22:52 ◼   ► to get lost in the shuffle, or it's more likely to get lost in the shuffle. So the

00:22:56 ◼   ► best time to file bugs is when they are actively looking for bugs ravenously, and that is early

00:23:02 ◼   ► betas. Like, right after WWDC, when you get those betas and you're trying out the new

00:23:09 ◼   ► stuff, they are looking very closely at bugs people are filing. So if you want things to

00:23:14 ◼   ► happen, that's the time to do it. Like, it's like the code is, like, open, it's,

00:23:17 ◼   ► like, being worked on. That's the time when they can allocate lots of their own time to

00:23:22 ◼   ► looking at your bugs and considering them. The worst time to file bugs or to make requests

00:23:29 ◼   ► public is probably right before WWDC, because that is, like, they are in a massive crunch

00:23:37 ◼   ► time every year trying to get stuff done for those first betas, like, for those first builds,

00:23:42 ◼   ► and anything you try to have them do during that time that they don't have to do is

00:23:46 ◼   ► going to get dropped on the floor, because they're just, they're way too busy. Also,

00:23:49 ◼   ► similarly, when it's right before the GMs come out in the fall, when there's about

00:23:54 ◼   ► to be new hardware released, they have no time to consider your enhancement request

00:23:58 ◼   ► then. Like, the OS is basically done at that point. Like, that's a terrible time to do

00:24:01 ◼   ► it. A good time to do it also, besides the early betas, is, I would say, the very beginning

00:24:07 ◼   ► of the year, January through March, maybe, because, like, usually they're doing, like,

00:24:11 ◼   ► a kind of an intermediary release cycle, like, the .2s or .3s of the OSs. It's kind of

00:24:16 ◼   ► a quieter time. It's a time when they might have more time to allocate towards improvements

00:24:20 ◼   ► rather than just, you know, core features. I just want to spend a quick moment talking

00:24:26 ◼   ► about tone and framing when you go public. So, if you're going to write a blog post,

00:24:32 ◼   ► or you're going to have, you know, any kind of public, you know, outing of what Apple

00:24:36 ◼   ► is doing or not doing or what you want them to do.

00:24:38 ◼   ► >>Steve - If you're going to become the elephant in the room.

00:24:40 ◼   ► >>Joe - Yes. It helps to, the way you frame it, and this actually should also probably

00:24:47 ◼   ► apply to the way you write bug reports too, the framing is very important. You want to,

00:24:51 ◼   ► instead of just saying, like, I want this to be fixed, well, that's, you know, you need

00:24:56 ◼   ► to frame it as, here's why it helps Apple, users, and developers, and they care about

00:25:03 ◼   ► them in that order. Developers are really last in that trio, like, you need to tell

00:25:09 ◼   ► them why Apple needs to do this and why that will benefit Apple's customers or the users

00:25:14 ◼   ► of your software. Like, that's what you need to tell them. And what you, what you as a

00:25:18 ◼   ► developer need is really low on the list. Because if you tell them something that will

00:25:22 ◼   ► benefit Apple, your chances are better. And the tone that you use in the wording and just

00:25:28 ◼   ► everything, headlines, titles, the best way to do, you know, Apple is, again, this is

00:25:34 ◼   ► a company full of people. I have found that culturally, many of the people there are pretty

00:25:40 ◼   ► sensitive to the tone with which requests and especially complaints are made. The best

00:25:46 ◼   ► thing you can do is to basically remain factual, you know, state the facts as neutrally as

00:25:54 ◼   ► you can. Any request or, you know, criticism that you're making of them, be civil and

00:26:01 ◼   ► be constructive as much as possible. Because what you don't want to do is you don't want

00:26:07 ◼   ► to give them a reason to disregard you as just being mean or just being a jerk or being

00:26:13 ◼   ► unreasonable. You want to give, you want to say, here's the facts, here's what we need

00:26:18 ◼   ► or here's what I need or here's what happened and, you know, here's what I think should

00:26:22 ◼   ► happen. And it's also important not to, they're very sensitive about this, not to put words

00:26:29 ◼   ► in their mouth or not to ascribe motivations to Apple. You know, there was a kerfuffle

00:26:35 ◼   ► last year with a developer where, like, he recorded a conversation with Apple on the

00:26:41 ◼   ► phone, like, without their permission, like that, you know, that's something you shouldn't,

00:26:45 ◼   ► you know, don't do that and don't ascribe motivations to Apple. Like, Apple did this

00:26:49 ◼   ► because they hate me or because they're being mean or because they don't want this

00:26:54 ◼   ► kind of app, you know, like, unless they told you that in some kind of public way, like,

00:26:59 ◼   ► you know, don't ascribe motivations or malice to Apple. Just keep it factual, keep it neutral

00:27:06 ◼   ► and, I mean, obviously this goes for a lot of communication in the adult world, like,

00:27:11 ◼   ► this is what you should do in general, but, yeah, like, if you keep it factual, neutral

00:27:17 ◼   ► and constructive, it increases your chances that you're going to be taken seriously

00:27:23 ◼   ► and that will improve your chances of getting done what you actually want to get done.

00:27:27 ◼   ► >>

00:27:35 ◼   ► I think that you should be able to think of Apple as a faceless entity, right, that it's

00:27:41 ◼   ► like, that doesn't have feelings, that doesn't have emotions, that is just this cold machine

00:27:47 ◼   ► that, you know, takes in code and outputs money, like, that's not the reality. Like,

00:27:53 ◼   ► it is, you are ultimately trying to, if you have a change that you'd like to affect,

00:27:58 ◼   ► you are trying to convince people to do that and the best way to affect people is to, you

00:28:04 ◼   ► know, be respectful of them and to be presenting your arguments in ways that is hopefully going

00:28:10 ◼   ► to ultimately make them look good, that is going to, you know, make their life better

00:28:15 ◼   ► in some way and you're going to have way more luck with that than just yelling and

00:28:19 ◼   ► screaming and throwing a fit because that's not going to help anything. Like, that doesn't

00:28:23 ◼   ► help if you're a two-year-old and it's definitely not going to help in trying to

00:28:26 ◼   ► affect change into a massive, you know, billion dollar company.

00:28:30 ◼   ► Exactly, because anything you are arguing, you know, as you said earlier, you are providing

00:28:35 ◼   ► ammo for an internal discussion. You want your side of the argument to win internally

00:28:40 ◼   ► and so if you make a really good case, people inside can use that to win arguments, to affect

00:28:47 ◼   ► change, to do what you want. So it really helps a lot that you make the best case possible

00:28:52 ◼   ► and that you, you know, choose things wisely to even argue about in the first place and

00:28:56 ◼   ► when you do, do it right. Play by their system, play by their rules and play by general adult

00:29:01 ◼   ► civility rules and you will have much better chances of succeeding.

00:29:05 ◼   ► Well, that's all the time we have for this week. Best of luck with everybody with your

00:29:08 ◼   ► Affecting Changes efforts and we'll talk to you next week.

00:29:11 ◼   ► Bye.

00:29:12 ◼   ► Bye.

00:29:13 ◼   ► [BLANK_AUDIO]