PodSearch

Under the Radar

99: Effecting Change

 

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]