I have a slightly different perspective (I worked on iOS 7 - 11). One of the things about Apple that's different to many of the other tech conglomerates is that engineering teams are given huge freedom to work the way they want (for better and for worse). Because engineering is so fragmented you should always take what one person says about the process with a pinch of salt.
So that means there are hundreds of source repos, patch review systems, and the like. When I was there I saw teams using Phabricator, GitLab, GitHub, plain e-mailed diffs, and more. In the same way EPMs and project process varies massively across teams, so what that employee experienced is by no means the norm. Certainly I didn't find this to be true at all:
> Nothing could be worked on if it wasn’t in Radar with a priority number attached and signed off by the teams’ EPM. No room for a side project or time away from your daily duties because there were always P1s to fix.
In fact, I worked on a major feature that was keynoted one year that came out purely because of my side project work. If anything it was a frustration to enter the "real world" where PMs had so much more power and influence than they did when I was at Apple (where PMs didn't really exist, and EPMs existed only to manage project timelines and drive features that HI / ID came up with).
Based on your experience there what would you say is the cause of the recent slip in software quality in both iOS and macOS? As an outsider it looks to me like they're just pushing too hard to keep up with a yearly release schedule but that's based on no inside knowledge at all.
> Based on your experience there what would you say is the cause of the recent slip in software quality in both iOS and macOS?
It's not clear because there have been absolute shit-show releases going back to the early days of OSX. Even the fondest-remembered releases were only so after a ton of polish, and that was with releases slipping significantly (you might see 3 years pass between major updates, and the new version would still be completely unstable).
I'm sure yearly releases don't help, especially if there isn't a postgres-type culture of "we ship what's ready", but software engineering issues at Apple go back a long time.
What has definitely changed is the pace with which people are expected to upgrade. When OS X Snow Leopard came out, you had to visit a store to buy the DVD. Nobody would look down on you for running a "legacy OS" if you only upgraded when .3 was out.
The ways in which this has changed affect both tech-savvy and casual users:
1. Older versions of iOS (which didn't exist back then) don't receive security fixes, so the only way to stay safe is to upgrade within days of the initial release (ideally before Apple publishes its security KB article).
2. Older versions of macOS often lag behind when it comes to security fixes. There is no clear policy on whether it is safe to stay on release n-1. Apple needs to be nudged to even document macOS security issues[1]. If you are moderately paranoid about security, you have to install all updates on day one (as on iOS).
3. iOS and macOS automatically download OS upgrades and nag you to install them.
4. There is a narrative on community sites that Apple's products are only good because Apple relentlessly kills legacy code and features (I don't even agree with the latter part). Dropping support for anything older than a year is considered a badge of honor because it means there will be "progress". The more paying customers you inconvenience, the edgier you are.
5. Apple feeds into this "old software is bad" meme by publicly LOLing at Android's adoption curve every year.
6. Emoji. I wish I was kidding, but only seeing squares when other people go out of their way to express their emotions is actually annoying.
7. If you are already on an OS that is buggy, you are more likely take the plunge and update to a brand-new OS in the hope that this time, things will be better.
> 3. iOS and macOS automatically download OS upgrades and nag you to install them.
This annoys the hell out of me. So much so that I feel like throwing the device every time it happens. What a waste of energy, storage, and network data limits! I've had to delete the iOS 11 download on my device manually several times already. I make sure WiFi is off whenever I'm charging for fear that it would automatically install the update too (not sure about this) and would not be able to revert back.
If anyone on the iOS team is reading this, I'm not moving out of iOS 10 unless you provide a way to turn off the WiFi radio from Control Center (not just disconnect from the network and connect automatically when I'm in a different location, which is not what I want). And also fix the slowness issues with iOS 11. I have it on an iPhone 7 and the performance is bad. I can't spend several hours erasing the device, reinstalling the OS and re-downloading all the apps (several tens of Gigabytes) once again now that you've not only removed app transfer and sync with iTunes but also removed the apps section from it. Stop assuming things about people's connectivity and data transfer quotas and start designing for real users!
Using an Apple device has never been so frustrating for me like it has been in the past two years.
When Snow Leopard 10.6 came out in August 2009, it only supported Intel Macs, which were at earliest from January 2006, about three and a half years earlier. Typical Mac OS X releases up to El Capitan (september 2015) supported 10 years of Macintosh computers. Sierra/High Sierra still do, essentially.
The support for older machines depends on multiple factors, like the multi-year transition from 32 bit to 64 bit for the OS, including 32 bit EFI, 64 bit EFI, etc. Some older machines were not supported by newer releases (not talking about security patches) for longer than five years, IIRC. That's a long period of time, but still quite short when compared to Windows support of older machines during that time (this is not a great comparison because of differences in annoyances and quality in the OSes, but more about the companies' work).
Right, but engineers probably are going to have some level of conviction and judgement when it comes to something they helped build. They're personally invested in a feature they've worked on.
If I was an engineer at Apple who worked on iMessage, and I heard acquaintances talk about the bugginess about iMessage, I would probably start out being defensive but then I would regret that we didn't ship a better product.
I think an EPM is less likely to feel like that, as they are not so closely tied to the actual product, which is what the Reddit poster was saying.
It's easy to blame "the other". Having worked at Apple I never felt like it was the EPM causing quality issues for us. It was us setting an aggressive schedule ourselves and, more importantly, having poor testing. The EPM was mainly just making sure tasks didn't get missed, reprioritizing them as the schedule moved based on discussions with managers & other engineers etc. Sure at some point in the schedule the central EPM committee for a release would start locking things down & punting less critical issues, but that's something that's done for every single release even for engineer-driven companies because you have to ship at some point.
Keep in mind also that these EPMs themselves tend to be fairly competent engineers in their own right so these aren't MBAs making decisions, they've just moved on as their career evolved. They care about quality just as much as anyone. The difficult part is making the call of cutting a feature especially if it's a keynote feature because there's just not enough time to actually ship it because that's predicting the future. Another difficult call is what bug constitutes a delay of an OS release, especially when the bug report may not have the necessary details to indicate it might be more critical than it seems.
TLDR: It's not as easy as saying it's all the EPMs fault. There's plenty of blame to go around because nobody is perfect & predicting the future (which is what scheduling is) is very hard.
It's really hard to put any single root cause on it. Firstly, mobile OSes are massive beasts with lots of different teams working on it. Co-ordinating this becomes very difficult. Additionally, you typically get about 1 build a day which means there's a long lead time to find a bug that's managed to propagate out and then a long lead time for it to get fixed (at least 1 day). I think this decrease in quality has been seen across all OS vendors, it's just that Apple has become one of the dominant OSes so there's more press about it than there was about previous Apple releases.
So now you have a larger volume of bugs since bug count is based on the amount of code written, assuming best case that developer quality is roughly consistent across all teams. Since you have a larger volume and only so many hours in a day, trying to ship all software at once at an annual cadence means your bug count will go up regardless of how much QA you throw at the problem (since in addition to finding issues you have to fix them).
Automated testing might help because you could catch bugs before they're even submitted. Well, automated testing is still very hard on these devices when you're building the OS. For example, how do you do something as simple as build & run unit tests? If the answer involves loading code onto a mobile device that means (at Apple scale) you need a farm of devices. Moreover, your test isn't valuable if it's running against yesterday's OS. Might not even build/run because you've now acquired a dependency on an API made available in the new OS. So now you have to co-ordinate building the software using an SDK that may be unstable (build breakages happen), run it on an OS you somehow have to pre-validate works otherwise & then have some confidence that the bug found was introduced by your commit & not some combination of build issue, compiler bug (oh yeah - the compiler changes drastically too while your building your next OS), or downstream dependency bug. Finally, on top of all this you need to make sure you can recover bricked devices in an automated fashion so that the maintenance overhead of your automated testing cluster is manageable. All of these aren't impossible problems to solve. The problem is that it requires a lot of effort & physical infrastructure. Additionally, Apple has had a very ad-hoc development environment where no 2 teams are the same (it was slowly changing to unify large pieces of infrastructure when I left) which complicates the ability to roll out central infrastructure. Additionally, there are different needs - the kernel has different testing requirements/strategies from system daemons, from drivers from 1p apps from backward compatibility testing.
When I left a couple of years ago Craig had actually directed his teams to improve the automated testing infrastructure but at the end of the day the software is growing more quickly than the investment that was made in QA. There's also only so quickly you can roll out central automation infrastructure to an organization as large as Apple so it's not as simple as "do more QA" or "add more QA resources" not to mention that "QA resources" in automated testing typically requires very skilled software engineers to design & build the systems. Allowing a longer bake time is exactly the right move here as it recognizes the need to decrease the volume of bugs while infrastructure catches up.
However, the contradiction is that single giant releases help in three ways. The first is it enables you to make 1 big splash of a years worth of work to customers rather than it being dribbled out of the course of a year across different components, which is super important because it dove-tails into the release of the next flagship phone. It also makes the messaging because you can build themes for your releases that are co-ordinated across many apps/services.
The second is that it co-ordinates large-scale changes across the company (e.g. major UI redesign, some major UX improvement, etc) which would be more difficult to co-ordinate with smaller releases or if apps were split out.
The third is that leaks/previews can be better controlled as managing a bunch of different releases that contain functional differences is harder than just maintaining bug fixes (i.e. prepping UI changes for 50 different apps that are released throughout the year in preparation for the next OS that makes it possible for those apps to run).
Finally, it simplifies development in a sense because you don't have to worry about 1P backwards compatibility. 1P apps don't have to worry about supporting more than 1 OS and OS changes can confidently break 1P apps (within reason) with new APIs without worrying about apps that haven't been updated. The latter part about breaking apps doesn't matter as much if the apps are bundled with the OS unless those apps can also deliver updates via the App Store as now you have to launch vehicles that can be tricky to co-ordinate.
Yes, a lot of this is pure business reasons for why the SW is co-ordinated but that doesn't mean that it's not valid. Business practices & SW are symbiotic aspects of a tech company as neither can exist without the other. Everything is a list of tradeoffs and priorities. Apple is apparently first experimenting to see if they can keep all the business pros of their current approach by altering their program management practices which they've already done - iOS & OSX today have far more dot releases in 3 months than they used to between major versions. Reducing scope is the approach they're taking in the interim to make the major releases more stable - will be interesting to see if this is a long-term shift or just an interim one until their QA infrastructure investments catch up to be able to keep up with development. If those approaches fail & the brand becomes at risk that may outweigh the other business reasons & result in independent app & OS releases (seems unlikely IMO).
Hmm... I think Kim came in towards the time I was leaving. Last name? When I was there our immediate QA was embedded within SW & reported up through the SW chain. Craig took over all OS SW development early 2015 IIRC. Have things changed? FWIW software quality of iOS has always been a concern in the media and I don't see that iOS 11 is particularly better or worse than other releases. iOS 8 had horrible performance issues for example to the point where iPhone 4S lifetime had to be artificially extended to iOS 9 instead of being EOL'ed in iOS 8 as originally planned. Every release has had its own share of embarrassing/severe bugs. Except for maybe iOS 1.0 which had no 3P features, a very small feature-set, & no competition to be evaluated against, each iPhone release has always been received as having stability issues, at least initially.
> The iOS 5 update was the subject of criticism for iPhone 4S users, as the upgrade caused problems with battery life, failures of SIM cards, and echoes during phone calls.
https://en.wikipedia.org/wiki/IOS_5
> A study by Apteligent (formerly Crittercism) found that the rate at which apps crashed in their tests was 3.56% on iOS 8, higher than the 2% found on iOS 7.1.[81]
> Forbes published several articles focusing on problems in iOS 8 regarding Wi-Fi and battery,[82] Bluetooth,[83] and calendar.[84]
https://en.wikipedia.org/wiki/IOS_8
Except for iOS6 & 7 which appear to have had a milder reaction, if anything I think iOS 11 may be a more stable release compared to iOS 8, 9, & 10 in that while there are more frustrating UI bugs you can hit (auto-correct, iMessage message ordering) but the overall performance & stability hasn't suffered as badly. Also iOS has knock-on impressions from OSX stability which has had similar UI embarrassments + a couple of security-related missteps.
My point is I don't think there's any single particular cause that's identifiable as the reason behind poor SW quality. If it were the hundreds if not thousands of really smart people Apple employs would have solved the problem. At this point it's all higher-level issues & more often than not tradeoffs (e.g. reducing the features you ship every year & going away from a waterfall development model)
When I've seen "always follow priority order," it's always been somewhere between "[wink wink] that's a good idea, figure out how to link it to the top-priority stuff" and "all priorities are negotiable" anyway. Was your experience similar, or just more of a team truly without external priority ordering?
Do you think some level of standardization of process would help apple as a whole? Would it help eliminate the relatively poor experience of reddit-OP?
I think it's both a blessing and a curse. On the one hand it makes it very easy for teams to find an approach that works for them, and does away with a lot of bureaucracy.
On the other, it promotes a lot of inefficiencies (I knew of at least 8 separate instances of Phabricator being used by different teams), and makes it very difficult to centralize core tooling and operations. It also makes it very hard for engineers to have internal mobility (you typically would have to do a full interview loop as an internal transfer, which is in stark contrast Google / FB's approach).
When I left there was talk of centralizing more tooling to attempt to alleviate some of these issues, but I don't know if any progress has been made since then.
There have existed teams at every company I have ever worked for who argue that this is the Very Best Way (tm) to develop code. It allows for the True Gatekeepers to keep their hold over the perceived software quality and quickly routs any sort of outside interest from modifying the project in any way the True Gatekeepers don't desire. In entirely broken organizations this is an effective way to allow 2-3 good developers to produce software in spite of the culture. In any organization beyond entirely broken, this prohibits a team from scaling beyond 2-3 key core members and tends to allow that small group to become the BOFH, maintaining a reign of terror over all non-blessed developers, regardless of seniority or title, who dare contribute to the product. In some senses this is the Linus "benevolent dictatorship," but in most, it's a despotic system that collapses as soon as one of the core contributors moves on or retires.
In my experience most attempts to move these sorts of teams towards real revision control and development practice lead to an extinction event in which they practice every form of hazing possible to maintain control, requiring careful management. Think extreme code-format nitpicking (combined with a lack of automated tooling or a styleguide that would let "others" get it right), followed by appeals to whichever authority maintained their team, outright hostility, and eventually ultimatum or holding the code hostage.
But how is emailing different from something like eg. Gerrit or pull requests. Ultimately, it's always the maintainers who get to decide what gets into the repo.
What you describe is a problem occurring independent of the way changes are merged. I agree that it can be a real problem.
I think your sibling post is similar in sentiment and it comes down to transparency. In the "patches-to-a-list" model, there's no running status page or record of exactly what patches were rejected or ignored, and by whom. Anyone wanting that information would have to go to a lot of work parsing, searching, and analyzing the mailing list.
With Gerrit or pull requests, reviewers are clearly assigned and patch states are managed in a centralized dashboard. This makes it a lot easier for external stakeholders (managers, other development staff, etc.) to gain insight into how a team's working and whether or not they're being accepting or effective. And that's why, to me, these kinds of toxic maintainers seem to suffer an extinction event when moved to a more transparent system. The maintainers are the same, but their tool - quietly rejecting patches with little accountability - is taken away from them.
Git itself is developed this way, so saying it could be fixed by "real revision control" is silly. Maybe you worked with someone who misused this model, but there's good reason Git and Linux use it.
Git hasn't been run by Linus for over 10 years, and uses this workflow. Is it flawed in some ways? Sure, but it works and has its advantages.
Furthermore the way patches are submitted, discussed and reviewed has little to do with the process by which they're eventually accepted or rejected by a BFDL maintainer, unlike what the GP is claimnig.
If the kernel used say Github pull requests you'd just have Linus rejecting some of those instead of refusing to accept patch serieses submitted by E-Mail.
The GP is just railing against some bad experience with the "True Gatekeepers", as if a company that was dysfunctional enough to use E-mailed patches as some unreasonable filtering mechanism wasn't able to do so via other methods.
The advantages of the E-Mail workflow is that it's fully distributed (aside from the ML hosting), bug/patch discussion can naturally flow into one another, everyone can use their favorite client that they can script etc., and you don't need an active network connection to participate (do all your patch review on the plane), all as opposed to using some opaque web UI.
The advantage of the Pull Request system is that it lends transparency. Especially in a corporate environment, a team can easily ignore and reject a lot of code sent to a mailing list. When each patch is tracked using tooling built for that purpose, this gets a lot harder.
Yes, the BFDL maintainers can continue to operate in whatever system they're given, but the more transparent the system is, the more likely they are to be discovered and the issue corrected.
I do agree that the E-mail workflow offers (a few) advantages, but the lack of inherent transparency in the tooling tends to be quite troublesome. It also doesn't inherently offer easy integration with automated testing systems or easy audit and compliance logging.
I certainly wouldn't recommend it for most situations, especially something like a corporate environment where most people have problems with basic E-Mail workflows like inline quoting and preserving In-Reply-To headers.
It's more suited for free software projects like Linux & Git where the participants don't want to be locked out of all their historical discussions just because some company does badly in the stock market, as opposed to being 100% archived in hundreds of places via an open protocol, and trivial to migrate somewhere else.
I'm just saying the problems you had with it seem to come down to a completely dysfunctional corporate culture, not patches over E-Mail.
Sure if you're working with such monumental assholes that they're just going to passive-aggressively and conveniently discard whatever you tell them over E-Mail / IM / at the water cooler that's pertinent to their work area and need to essentially CC their manager on all correspondence, and are using PRs as a way to do that.
Then sure, then an E-Mail-based workflow probably isn't for you, although you could use git-format-patch to CC both your and their manager on every patch you send to achieve similar results.
What's not to like? Lightweight, multiple interoperable tools (MUAs and editors), no barrier to entry, easy to review and comment. Compared to shitshows like Gerrit and the awful clunky workflow of Github, I'll take an emailed patch every time.
Does it scale to huge patchsets? ... well not so much. However Gerrit is not the answer to that (in fact, no tool I've found provides a good answer).
The major problem with the email-patches workflow is that it is a pretty poor experience for the new and occasional contributor, who will generally find that their email client makes a complete pig's ear of their patch. What I'd really like to see is a web UI that seamlessly interacted with the trad email workflow, so people who prefer a web UI and especially people who are just making a single drive-by contribution could work that way without having to start by setting up git-send-email. You could also make the web interface keep track of which patches are still unreviewed so things drop through the cracks less often...
I'm a former iOS EPM (not speaking for Apple, obviously, since I don't work there anymore), and although the Reddit commenter got the atmosphere of constant crisis right, he/she is misplacing the blame and misunderstanding the power dynamic. EPMs at Apple essentially have zero power over engineers' workload. They take the list of stuff the engineering managers said they want to get done this year and say "You guys are crazy, you'll never be able to do this without 3x the hours/manpower." Then they proceed to drive the team as hard as necessary to make sure that they actually deliver what they said they were going to deliver. That's it. The idea that there is this cabal of mighty EPMs twirling their mustaches and loading developers down with work is pretty far from reality.
It's true that you shouldn't be working on anything not in Radar (the bug tracker) but this is true anywhere you'll work. Project managers however do not sign developers up for all those radars--on the contrary--we're usually trying desperately to help you get rid of scope and get the task list down to what's actually do-able!
One of the great things that IMHO sets Apple apart is how engineering-driven they are. I've never worked anywhere else where engineers had so much freedom to decide what they're working on. The fact that they always decide to work on 3x what they can actually achieve is kind of on them. But that drive to try to do so much is part of what keeps innovation strong at Apple.
The comment was half-right in describing the situation radar-obsessed culture (Radar-Driven Development?)
It places the blame on EPMs because EPMs are just the bearer of bad news, middlemen who carry out the whims of the UI Gods and VPs. The original commenter couldn't see those above the EPMs, the ones overseeing the BRBs and other inquisitions.
We use the bug tracker for coordination and collaboration. If you have a customer-affecting bug or a stakeholder-facing feature you’ll use the relevant task to discuss it, but we certainly don’t let the bug tracker dictate how engineers spend their time. That sounds like hell.
That's the norm in any medium to large sized engineering organization. PMs set out what needs to be worked on and want to know the progress on these tickets. How is that unreasonable? Maybe it would help if you referred to it as a sprint board rather than a bug tracker?
Within the project I was assigned this quarter, I decide what needs to be worked on. Most of the tasks on my screen were created by me and represent details that my product manager neither understands nor cares about. They're involved in master tasks for deliverable units of functionality and inbound bugs/feature requests. My PM and EM like to hear progress and like to have some idea of what I'll be doing in the coming week, but I'll pretty often have and scratch an itch in the same day, without necessarily going through the motions of writing up a task. (We do have code review, and I'll probably mention it at standup). The existence and level of detail in a task really depends on the number of people who need to be involved and how much we need async communication.
If this is atypical, I'm terrified to ever leave my large engineering organization - it's a pretty great model for the work we do.
I think the craziest thing about this comment is how juxtaposed it is to the original one. How you could have such divergent opinions on org structure or team dynamic is mind blowing.
The fundamental unit of team dynamics is what, maybe 8 engineers? Companies like Apple have thousands.
Even working somewhere, sure, you'll know what the adjacent teams in your org are like, and maybe you'll meet some internal transfers, but the truth is you have no idea what life is like for the thousands you'll never meet. There might be broad strokes that differentiate the company from its peers, but only the vaguest outline is going to be universally or even mostly true.
Well this just further convinces me that Apple’s problem is lack of man hours. If the problems are due to trying/wanting 3x what your capable of... you’ve got two options. A: reduce your expectations. B: increase your capacity so you can achieve it.
Given Apple has a pile of cash so large it could do pretty much anything it wants... and have had for several years now... I’ve begun viewing their continued unwillingness to aggressively pursue opinion B as a failure of “upper middle management” who are clearly either suppressing the needs coming up from below, or in the very least, not pushing hard enough to their bosses that their teams are under resourced for achieving the companies goals.
Breaking: Engineer Thinks PM is a Bozo. Film at 11.
It's not really context. The real problem here is the premise that "Apple has software quality issues" is taken as a given, without support.
Sinofsky makes the point that Apple is operating a such a huge, unfathomable scale and depth -- and this is coming from one of Microsoft's top guys in its heyday -- that even rare bugs that affect 0.01% of users translate into a "stadium full" of people, affecting their lives deeply. So, combine that with a sensationalist, anecdote-driven news cycle and you get an optics problem. He observes that "in any absolute sense," Apple's SW+HW quality has "exceeded everyone else."[1]
It's not "Engineer thinks PM is a bozo", it's a post explaining a very concrete, objectively negative behaviour from the PM team. I've worked at companies where that sort of behaviour was rampant, I've worked at places where it wasn't, and the difference in the end product is palpable.
Second, even if it's just anecdotal, I have personally been experiencing issues with my tMBP at work that I haven't had with any previous laptops going back to a G4 iBook. Stuff like random crashes, parts of the screen failing to render properly, etc. IT says that they're experiencing more of that sort of complaint with the current gen than they have with others in the past. The "sensationalist anecdote-driven news cycle" is blowing things out of proportion, to be sure, but there does seem to be some measurable degradation in their Apple's standards as of lately.
> It's not "Engineer thinks PM is a bozo", it's a post explaining a very concrete, objectively negative
> behaviour from the PM team. I've worked at companies where that sort of behaviour was rampant, I've worked
> at places where it wasn't, and the difference in the end product is palpable.
Yeah, I'm not a fan of dismissing complains by saying that its normal for engineering to think that way about PM. There are different mindsets involved and it is definitely normal for them not to see eye to eye all of the time. It is also normal for them to want to prioritize things differently and there are some delicate balancing acts to be played between meeting legitimate engineering needs and pragmatically driving a product forward.
But sometimes, the PM really is causing problems by preventing those things from happening or by getting in the way of his own objectives.
> even if it's just anecdotal... there does seem to be some measurable degradation in their Apple's standards as of lately
You just characterized anecdotal evidence as "measurable". That's exactly the logical fallacy at work here.
Non-anecdotal evidence of Apple's quality standards: The super long iPad upgrade cycle. It's stretched out and impacting Apple's bottom line because >3 year old iPads still work perfect.
It funny, while rare bugs are part of the problem, fundamental design is a problem that confronts me much more. The epidemic spread of animations that reduce functionality and responsiveness are pretty unforgivable. This is something that affects all users that try to interact with their phones, and I'm getting pretty sick of modal switches between "accepts touch input" and "doesn't accept input" when there are no visual indicators of the modality of the current moment. Oh how I long for the old iPhone 4 and it's greater responsiveness and more fluid UX.
Animations are one of the reasons I use Android. iOS is just littered with gratuitous animations that needlessly slow down the interface. My two least favorite are the home screen zoom-in effect you get every time you unlock the device and the animated text on typing autocomplete suggestions. And you can't disable either of these without disabling system animations entirety.
This stuff is symptomatic of Apple's love of form over function, also manifested in dumb and costly UI gimmicks like 3D touch.
Properly designed animations are function: they give a sense of place and help in creating a navigation hierarchy instead of having things pop into and out of existence.
> iOS is just littered with gratuitous animations that needlessly slow down the interface
Their gratuitousness is evaluated by you by the "slowdown" they bring. The only slowdown they bring me is when they're not interruptible/concurrent, but that's a bug, like the calculator app's one.
> My two least favorite are the home screen zoom-in effect you get every time you unlock the device
Unless I'm literally trying to race the beam, by the time I move my finger from the home button to a position over the screen the animation has completed. The animation is interruptible and you can tap or swipe right through it.
> and the animated text on typing autocomplete suggestions
How is that slowing you down? You just type <space> which triggers the animation yet merrily continue as the animation proceeds while you are already inputting the next words.
> costly UI gimmicks like 3D touch
To each his own: I use it everyday to peek at things and multitask, it's a real timesaver.
My issue with 3D Touch is that there doesn't appear to be any language for when you can use it or what it will do if you can.
90% of the time, I forget it's there.
A specific case of where it was a problem for me is that tapping the lockscreen icon for the flashlight does nothing. I thought it was broken for a week till I accidentally discovered that you had to force push it.
Unless I'm literally trying to race the beam, by the time I move my finger from the home button to a position over the screen the animation has completed.
My brain can't identify the icon I want to tap while the animation is in progress. I have to wait for it to finish then parse the screen for my target.
You just type <space> which triggers the animation yet merrily continue as the animation proceeds while you are already inputting the next words.
Again I can't identify the word I want to tap while it's moving around. I have to wait for the animation to complete, then figure out if I want to tap any of the suggestions or keep typing.
I agree animation can be functional, but both of these animations are purely there for aesthetic reasons, get old very quickly, and actively slow down my use of the device. If I have to use an iPhone for any extended period of time I turn off animations at the system level and use GBoard for typing.
As for 3D touch. I always forget it even exists because it has zero affordance. It increases the manufacturing cost of the device for very little user benefit for the typical user. I think it also forced Apple's hand on FaceID and drove the cost of their flagship device out of the range of a lot of people that would otherwise buy one.
> My brain can't identify the icon I want to tap while the animation is in progress. I have to wait for it to finish then parse the screen for my target.
Interesting. I sure don't parse each icon precisely as it moves but the colors and layout allow me to intuitively have my bearings and know which page I'm on and then it's muscle memory. I can see it being an issue though.
> I have to wait for the animation to complete, then figure out if I want to tap any of the suggestions or keep typing.
Oh my bad, I thought you were talking about the autocorrection bubble that has the word come down on <space> but this is really about the predictive words above the keyboard. I turned them off entirely because I basically never used them and it seems to make the keyboard itself terribly slow after some time as it computes suggestions.
> As for 3D touch I always forget it even exists because it has zero affordance.
So are keyboard shortcuts, 3D Touch is not a requirement for using the phone but it allows one to be more efficient without cluttering the interface. Also, you typically don't forget that you can scroll or pinch to zoom on an image or map or whatever, it's kind of the same deal.
Oh one more I just can't live without now: force pressing on the keyboard turns it into a touchpad for the caret, and re-forcing it starts a selection.
> It increases the manufacturing cost of the device for very little user benefit for the typical user.
When I saw it demo'd I thought "what a gimmick", yet now it gives me so much value that any device without it feels gimped to me.
Regarding keyboard shortcuts, at least, on a desktop there are standard affordances for showing what keys will trigger an action.
When browsing a menu bar or looking at a dialogue, labels will usually have an underlined letter (sometimes revealed by pressing Alt) that indicates you can press Alt+<letter> to trigger that action. Items from the menu bar will typically list their corresponding hotkeys directly.
This is true across pretty much every desktop UI toolkit, even, surprisingly, in the Electron based Slack client I have open right now.
Android has a lot of gratuitous animations as well. To give an example, the Clock app on my Pixel animates the tab icons, which I find dumb and annoying.
At least macOS gives you the option to disable gratuitous animations with their accessibility settings. I'm hoping eventually Android will wise up and follows their lead.
> developer mode which comes with its own set of drawbacks
Not really, you turn on "developer options". There is no developer mode as such, just many separate options, all with defaults that don't change things from non-developer behavior.
I have animations set to 2x regular speed, it's nice.
"There are only two kinds of languages: the ones people complain about and the ones nobody uses" - Bjarne Stroustrup
I've found that quote to apply to everything. Familiarity breads contempt, even just from boredom, or wanting to shift blame for the monotony of the task you're using the tool for.
For example I think Excel is a great piece of software, but I know someone who spends all day every day in it doing dull but important spreadsheets. They're what I consider an Excel expert. But they hate Excel because every little minor issue is magnified for them because they spend all day every day in it.
I agree that this kind of criticism exists. However, that doesn't mean that all criticism is invalid, or that a large amount of criticism is necessarily a marker of success.
Some software examples: Internet Explorer has not been winning the browser wars for a decade. I've deleted Skype after its interface had been sufficiently ruined, and I don't know anyone who still uses it for business. When iTunes got too annoying, I left its ecosystem for Spotify. It's not looking good for Siri in the battle for the smart home. Speaking of programming languages, I complain a lot about Swift, don't use it, and am moving in the general direction of IntelliJ IDEs.
Excel and C++ got lucky, they will be hard to replace.
Absolutely agree with Sinofsky here to a large extent - there is little precedent at the scale some of these companies are operating at in 2018. My original comment was to more spark a certain type of discussion more than anything else.
It's cool to see other Apple engineers and PMs chime in with their perspective.
It sounds professional to need permission to spend time on something? I typically associate professionalism with the model where you’re accountable to the functionality, impact, quality, and health of your components, with an EM supporting your negotiations around scope and timelines, and letting you budget your own time.
I mean, nothing in the quote suggests that programmers can't submit items to Radar, that they can't lobby for them to be assigned a high priority, etc. Pretty much every software project beyond a certain scale uses an issue tracker of some sort.
If you need to lobby for permission to work on something broadly within the scope of what you're paid to work on, you aren't being treated like a professional.
An issue tracker is a communication tool for use in the context of a largely self-directed activity. The only role at my company where your day-to-day activity is dictated to you by the tickets on your screen is customer support.
On my team, if you're only working the asks handed down from above and not proactively taking initiative to make things better, you're barely pulling your weight.
> On my team, if you're only working the asks handed down from above and not proactively taking initiative to make things better, you're barely pulling your weight.
The problem with a lot of engineers is that "make things better" often doesn't translate into "keeps customers happy and money coming in".
I could work on making our internal software "better" for the next two years but it wouldn't bring in enough money from customers to justify paying me to do it. And I'm smart enough to know that I have zero idea about what will make things "better" for the actual customers.
The customers will eventually suffer a death of a thousand cuts through quality and reliability issues if direct attribution to revenue / customer requests is a requirement to work on anything. But of course you can't rewrite ever time you hear about a new language. Obviously there's a balance, and striking that balance correctly is a huge part of the job.
If engineers really ran a company, progress will often slow down. For example, if you're surrounded but a lot of young talent, the phrase that you just constantly hear is "refactor". Not as many developers enjoy bug hunting as they do new feature development. I suspect that those of us who've been in the field long enough end up growing a much greater appreciation for PMs and they decisions they make make than when they first start out. Or maybe I've been fortunate to work with really great PMs?
It is important to strike a good balance. One should neither ignore input by the engineers, nor give them a completely free hand. Refactoring can be a benefit for the future, but it should not grind progress to a halt. Senior engineers should give valuable input there. And of course, sometimes a seemingly crazy idea by a young talent is actually a good one :).
By broadening your vision. As an engineer, it's easy for me to focus only on technical details. So I make an effort to see beyond that -- what is our org's broader goal; what are our industry's issues? It's not always easy, and sometimes I'm overwhelmed, but it helps build a common vision, which can be the foundation for teamwork across disciplines.
What I meant was: How do other parts of the organization know what's being worked on? How do marketing, sales, product management influence the decision making process? GP made it sound as if engineering on its own decides what improvement to work on next. How does that work in the context of the larger organization?
Taking the bigger picture into account when designing a solution is simply good engineering practice. I don't think that's what the GP was talking about.
The organization communicates extensively to select a set of projects (at a fairly abstract level of definition) each quarter. Engineering managers assign projects to engineers. As a project lead, you design an architecture and implementation, circulate an RFC, break down the work, write much of the implementation, and maybe delegate components to 1-2 more junior colleagues, mentoring them in the process.
The EM and PM are often in the room with you to support conversations with stakeholders/dependencies, absorb the brunt of cross-team communication, make tough prioritization calls, and to monitor the progress you report via the bug tracker and in weekly sprint planning sessions. The engineer is responsible for determining what part of the project to work on next, and how to spend each hour/day/week in the service of its completion. PMs/EMs are only going to challenge your plans if they're egregious, and it would be unwise to create a sprint plan that would require 100% of your time.
Most people have interviewing and mentoring to do, several previous projects that occasionally need their attention, code reviews to give, operational incidents to attend to, etc. even before you consider the undocumented tech debt fixes, refactors, and productivity investments that aren't necessarily even mentioned to PMs.
If you spend too much time on that, of course, you'll fail to complete your projects, stop getting interesting assignments, and have no hope of promotion. If you spend too little, however, your projects will turn out to be operational/maintenance nightmares that may even be worse for your reputation and prospects than vaporware.
Each engineer is their own architect and project manager, with the scale of the project tailored to the engineer's level. (You advance by earning and then succeeding at increasingly complex project assignments). Product managers help determine the vision of what the product ought to be; engineers get it there.
Well ok. If "task" to you means a months-long initiative with hundreds of constituent parts, what do you call the items that take a few hours to a few days?
That post is not particularly useful - each team/org works differently. “Working on iOS” is such a vague introduction, it doesn’t really give any indication of his/her role or a feel for how every team/org operates.
I can claim the same, and my own experience has been far from that poster’s experience. Any time I have volunteered to spend extra time to accomplish a goal, I have been told by my manager that it isn’t necessary for me to do so. We also do our own planning on our team and the management chain is there to help us be successful.
Based on this comment, it sounds like engineers are more like line workers.
"EMs at Apple are powerless to push back. Every engineer's performance is tied to the number of Radars fixed and closed. Every EM's performance is tied to their team's total Radars fixed and closed, so they have an incentive to keep everyone focused on the prize."
Always take comments like that with a grain of salt.
The people who feel they are being ignored or feel they aren't being used to their full potential are going to look for someone or something to blame.
I'm sure there is some amount of "higher number of fixes is better" going on (any larger company has it), but i've seen poor team members read into things like this way too much in order to justify why they aren't doing well in comparison to others.
It may be true that apple weighs stats like that too heavily, but we aren't going to get a good picture of how heavily they weigh them from a few anecdotes.
Never saw or heard anything about my performance being tied to the number of radars I fixed or closed, and I never heard anyone else I worked with say that either. Doesn't mean it didn't happen, like every big company there are managers who are good, and managers who don't really get it.
Thanks for the perspective Klathmon and objclxt. The person's comment hits a fear of mine that people still draw the false analogy of manufacturing for software development.
Steven Sinofsky has a good Twitter thread about this [1]. He's one of the few people actually qualified to talk about managing platforms and operating systems at Apple's scale.
Someone should do this poor guy a favor and set him up with a blog. Twitter is only slightly worse for writing essays than "yo" (yes, it exists; no, I have no idea whether it's a joke).
Steven Sinofsky wasn't in charge of Windows Phone when that division decided to have no device upgrade path from WP7 to WP8 (or, for that matter, no upgrade path _or_ application compatibility from WP6.5 to WP7.0).
The person in charge of Windows Phone then was Terry Myerson, who had an entirely different reporting chain to Steve Ballmer from Sinofsky's. Myerson was later promoted to run R&D for all Microsoft operating systems in early 2014. (Yes, that means he was also the person responsible for killing Windows on phones most recently, at least for now.)
The death of XNA also didn't happen under Sinofsky's watch. XNA came out of the Xbox division and was abandoned by the same division, before it was combined with Windows under Myerson. If anything, Myerson kept XNA alive longer by making sure it was still supported on WP8.0 and WP8.1 when he ran Windows Phone, and by ensuring that Windows continued to fund MonoGame as an open-source successor/replacement for XNA.
If you keep up with Sinofsky's writings, it seems like he's learned a lot of tough lessons from making some pretty big mistakes and come out the better for it.
This is sorely needed. Every iOS update has introduced bugs and UX gremlins that have been dragging Apple's software quality through the mud.
Chief among them is Apple Music, since it is a huge part of Apple's service initiative.
- Their latest update now wastes space to tell me it isn't playing anything!
- Often times just refuses to work. No error, no graceful recover. Just silence. https://imgur.com/a/VrO1Y
- Airdrop seems to only work if I have a cable near me. When I really need it, it fails miserably and I end up using dropbox or even emailing things to myself.
I don't encounter many bugs, but I'm considering getting android because Apple's feature/UX choices are beyond insane today. There are two features they're missing, that I feel should have been one of the first few added.
1. You can't view a list of chapters in iTunes, like in Audiobooks from say, Audible. Awful. I mean, I hate to be unkind, but are they seriously this inept to not include a chapter list that you can view and jump to?
2. You can't keep the screen on while on a call, like say a conference call, where you might want to remain muted until you want to speak. Awful x100,000,000.
The problem here is that the “top 2 features that should have been in place from day 1 and represent an insane usability gap” are different for every user. So if they try and add all the weird corner case niche features, it’ll be the standard unopinionated bloatware that most software is.
FWIW, I’ve never played an audiobook in iTunes (Audible), and I hadn’t ever noticed the screen locking during calls thing. TouchID is so fast that it never bothers me, I guess.
>So if they try and add all the weird corner case niche features, it’ll be the standard unopinionated bloatware that most software is.
While I agree with the sentiment behind the argument, these days the pendulum is swinging far too much in the other direction.
Sure, this choice is always a tradeoff.
But today, so many applications and websites are being optimized for the one single most important use case at total expense for everything else. Making the software a true lowest common denominator, but seriously reducing actual usefulness.
Just look at the example: I don't have hard numbers, but I'd wager that "Show table of contents for an audiobook" is only a "weird corner case niche feature" for a very wide definition of the phrase (i.e. "everything below my main feature").
Are you sure you got the last update? Because Apple music has been a PITA for me too (especially that I use it with my car bluetooth) and I had the same issues you mentioned here.
However, all the issues were fixed in the last update and so far it is pretty solid. No complaints. (iOS v11.2.5)
Eh, no. I have playlists I made years ago. I click on them, crash. Probably some of the items are not available in Music, as they were from my personal iTunes library, but do I care? Nope. It just ensures I will never pay for this sub-standard service.
To be honest, I'm not sure why you think your experience is the truth out there. I have found that when it comes to Apple hardware/software, the experience can differ greatly from a person to another by cheer luck.
For example, I had no wifi issues with my MBP Late 2014. However, I remember lots of people raged about my particular edition's Wifi. It just happened that my particular laptop was fine while a significant batch was affected.
I had a horrible iPhone experience before the last update. The crashes were daily, the bluetooth dropped a lot, car integration was working 1/3 of the time and the interface was sluggish.
As of the last update, many (maybe most) of the issues were fixed. There is still a bit of sluggishness of Chrome and the very occasional crashes. But nothing for me to rage about.
Are you calling me a lier? That’s not very nice of you.
I have two different iPhones (6s and 7) and an iPad Pro, all of them behaving in the same identical way with respect to these playlists, which used to be fine in pre-Music iTunes. I don’t care if I’m the only person in the world experiencing this bug, but I can assure you that I do see it consistently. Being an extremely light user of the app, I expect there will be lots and lots of heavier users out there with much worse tales to tell.
ITunes on windows has just become unusable to me. Right now when I open it it gets caught in an inifinite loop of login prompts, even if the credentials are correct. It has never been good but right now it is just utterly broken. And every new update brings new catastrophes to the point that I delay them as much as I can.
iTunes on windows and Apple music on Android made me cancel my subscription and switch to google play music. I was amused that Apple software was so bad across two different systems.
I open iTunes like maybe twice a year. Last night I opened it and only logged in once.
I plugged in an old iPad 3 the hadn’t charged in 9 months or so and I discovered one thing. The password it was asking for to access the iPad wasn’t my current iCloud password. It was the iCloud password I used to setup the iPad. A little frustrating when I didn’t remember it but once I removed the device from find my iPhone everything worked.
Yea, I hear you. For me, Apple Music randomly pauses my music when it is on bluetooth or ipod dock every 60-90s. Googling it revealed that I am not alone and this issue has been going on since the introduction of Apple Music app. Every release I try again, but no fix so far.
Speculating here, but I suspect that it's an app in the "background" that is causing the issue.
As much as I like Sonos, it exhibits bad behavior with its background task that requests priority audio. If I have the app even running (even in the background, but haven't force quit it), it will interrupt the stereo in my car if I'm trying to listen to terrestrial radio and keep forcing CarPlay to open until I force quit the app.
Good. Let's hope that other companies follow (MS, Google, Adobe, etc...).
What I want for Christmas is to swap phones with Tim Cook for a week. I think it would be eye-opening for him to have to use an iPhone that isn't fresh out of the box for once.
>The company will continue to update its software annually, but internally engineers will have more discretion to push back features that aren't as polished to the following year.
Let's hope Microsoft follows suit. I would much rather have a product that works the same way every time over one that can do 1000 things half the time.
Hopefully this will also give them time to reconsider some of the more ill-conceived UX choices they've made in recent years. If they'd spent more than 6 months using the iPhone X I doubt it would've been released as is.
I don't think Microsoft has a code quality problem at all. On the contrary I'm hard pressed to point at any recent Microsoft software and say it's bug ridden or low quality or badly designed. From iOS to Android to Windows, Microsoft software is excellent.
It could just be because of the totally inconsistent UI across Win10 that I feel like things are more broken than they are...
Also to point to a specific problem, OneNote in iOS takes ages to open and get a note ready, I don't know what it is but it's the only app that takes that long to open.
It’s “fixed” in that the PM decided to gaslight everyone on that thread by claiming pointer events are what people are asking for.
It’s not. People want working scroll/wheel/touch events. They think the entire web dev world is going to rewrite stuff to support like < 5% of 3.86% of web users. Good luck with that.
Funny how Chrome supports the exact functionality they keep claiming is impossible to support.
Note also that there’s no way to detect Edge with working events vs Edge with a precision trackpad where events aren’t dispatched to the DOM.
From an enterprise POV, I experience the opposite. We haven't rolled out W10 in production yet, but just looking at the test/key user machines who have it, Windows updates have become markedly worse. A real lottery regarding reliability and stability, no comparison to the past.
The constant nagging for updates could be considered a flaw in design. I think Microsoft has always had the reputation of producing buggy software with usability issues. I think they have gotten a lot better at all that.
Definitely stuff like NSA-level telemetry and aggressive updates are bothersome. I was talking more from a programming perspective. They seem to put out comparatively bug-free and performant software. Specially on android, I was surprised to observe that Microsoft's apps are generally better designed and more useful than Google's own stuff.
Very true.I knew a future trader lost lots of money because she's win10 pc get a update, and she don't know how to deal with it, she couldn't stop it being updating.
Slack has threads that are (in my biased opinion[1]) way worse than Teams threading. I used to use Slack and currently use Teams. They each have their pros and cons but Slack threading was terrible.
Outlook for Mac crashes every time I try to create an appointment. I have to use a combination of the Office 365 and the desktop version because they don’t have overlapping features. I am perhaps prone to hyperbole, but it’s amateur hour in Redmond.
I have to use OWA (outlook exchange webapp) for search because MS decided to use Spotlight for search - which I have disabled as it is a massive CPU, battery and RAM hog.
Have they fixed the issues with the Fall Creator Update of Windows 10 yet? It basically bricked every workstation that we let update to it, and we had to wipe them and put LTSB on to get back to work.
I Just opened the website on my phone and was greeted with some auto playing video. How much of my monthly data that costs? No idea, but it is probably more than I cared for. How much of it did I watch and hear? Nothing seeing as I am on the bus. Not so strange as I am on a _mobile_ phone. I wouldn’t even watch it on desktop let alone now. Bad practice
This rumor has been around past few months, hoping it's true. Though while us technies in the minority would rather bug fixes than new features that don't apply for us, the general public would be very upset if iOS12 changes are all under the hood, as they would say Apple has fallen behind and people will insert common statements every years like they are finally considering switching etc. So while I hope the do fix long standing small bugs, I think the average user would lose their mind if they do. I imagine it will be a mix, some new features and some fixes.
> So while I hope the do fix long standing small bugs, I think the average user would lose their mind if they do.
I really don't think they would. If you asked any person on the street what new features came with iOS 11 vs iOS 10 I really don't think they'd be able to tell you. It was a very minor upgrade, and no-one really seemed to care. A number of people I know try to avoid updating because they mostly associate it with a slower phone!
The Mac has had an optimization-centric release following a feature release many times (all the Snow releases, El Capitan). I don't remember mass complaints.
(By its name, High Sierra ought to be an optimization of Sierra also, but its bugginess suggests otherwise.)
There wouldn't be mass complaints. My family are absolute non-techies, while I am something like a techie, and none of us would complain if Apple did a few pure bug-fix releases. Non-techies don't completely understand the current situation where developers care far more about themselves than their users, but they have learned that software "upgrades" will usually waste their time and make their lives worse. Apple can actually fight this, since their users are their customers.
I think the iPhone has historically had more of an attitude of "look at all of the awesome new computer-ey things your phone can do!", whereas computers have always been treated more like appliances. It's much easier to tell a user "the new version of Mac/Windows has absolutely nothing new you care about." than to sit by the wayside while android devices have split-screen and curved displays.
Consumers and shareholders like cell phones because they're shiny.
The next update will bring a revolutionary new feature, an original invention by Apple, a courageous leap forward. It will bring STEREO playback to its homepods!
It cannot play from stereo separated with two connected speakers. The unit itself, however, has 7 speakers and it does separate the left/right stereo channels to different speaker pairs.
"They" already said that when iOS abandoned skeuomorphism, and "they" were damn right. A friend of mine who is not even a tech guy put it very bluntly: "Apple used to change things to make better phones, now they change things to keep up with what others are doing".
They abandoned skeumorphism because pixel perfect design doesn't work when you have multiple size screens. At the time they had two - a 3.5 inch screen and a 9.7 inch screen. Now they have four different iPhone screen sizes and three different iPad screen sizes.
When you had a picture as the background of your screen in 2010, you needed different images for different screen resolutions - 1 and 2x for the 3.5 inch iPhone and 1x for the 9.7" inch iPad. Then the iPhone 5 came out with a different ratio - you couldn't just stretch the image and make it look decently. Then two years later you had the 6 and 6+ phones with different ratios. Then different ratios for split screen iPad in different orientations.
Skeuomorphic doesn’t mean using background images, it’s just a matter of trying to have GUI elements look and behave like physical objects would. You can do that using textures.
How would they look if you squished it for 25%, 50% or 75% split screen view on the iPad? How would it look on the iPad Pros? In landscape? In portrait?
Usually what you're doing in those cases is that part of the image are stretchable and other parts are fixed. It's a technic that's been used for rounded buttons for ages, and can be applied to pretty much anything. That's also part of xcode (unless it's been removed).
But generally, you can easily have those kinds of design work with any kind of screen dimensions. It won't look completely similar from one size to another, but still look realistic (bigger screen -> bigger objects, or more space between objects).
I just hope they can make Spotlight work. I can drag down from the home menu, type the full name of an app on the phone, and only get random other results (or the App Store link to the app.)
e.g.: https://imgur.com/a/jYE9M (reminders is a built-in app but apparently Spotlight's never heard of it)
You can manually select which apps can be found with Spotlight in the settings app. I had the same problem finding 1Password until I went into settings and explicitly added it. This is terrible UX, but that’s how to fix it on your device until Apple sorts it out.
Thank you for this! I had no idea, but about half the apps on my phone were randomly set as "do not show in search". I definitely never had seen these settings before, so am boggled as to why Apple just randomly decided to ship an ineffective search.
I'll hold my praises until I see how this actually works out. Xcode behaves more like a roulette wheel with every update and by now, even Terminal crashes on me every time I use it. It has gotten to the point where I consciously avoid using Apple apps because It Just Doesn't Work. Thank the gods of FOSS for iTerm2.
After one of the recent updates, if I use a keyboard shortcut to switch to a tab while the mouse is over the Terminal window, it starts to rapidly cycle between tabs and will not stop until I move the mouse away. You can try to reproduce this by opening two tabs in Terminal, moving the mouse over it, then pressing Cmd+Shift+] for more than a few tens of ms.
This has interrupted my workflow enough that I started to look for alternatives to Terminal.
This is a very common problem in large software companies that I can relate to. There is always pressure of the next big release and as a result bugs get punted, code starts to get out of order but there is not time to refactor and pause as the next release is just behind waiting for more features and limited bug fixes. Software Engineers and Management need to re-think of a better strategy to deal with these issues.
I wish they would put focus on macOS. The recent bugs have been laughable. I am seriously considering switching for the first time in about 16 years. The lure of better more affordable dev hardware is almost to much.
The options are not strong elsewhere though. I went with a precision because I assumed linux support would be top notch, and it was. But I widely suspect other similarly classed devices are not. (see also; the comparatively buggy XPS series also from Dell)
Please enable per-app VPNs via Apple Configurator, i.e. without an enterprise MDM. This will allow separation of work and personal VPNs.
Please allow auto-connect VPN profiles to be associated with a whitelist of SSIDs, so that insecure networks (e.g. coffee shop) will auto-connect to a VPN.
Finally, please add a Control Center button to reconnect the default VPN profile.
It's not perfect, but I think that's what network location is meant to be used for. Check out: How to use network locations on your Mac [0].
I wish you could trigger more preferences automatically based on location or other factors. For example: I only want to enable certain sharing features when I'm at home.
Not a UI feature, but I found this guide last fall and have been using it flawlessly since. I whitelisted a few SSIDs and everything else goes through the VPN. Even works with walled auth garden networks like xfinity wifi.
Agreed on all of those. Additionally make re-connecting an iPad to an iPhone sharing a connection automatic (optionally) if no known wifi networks are available.
For those of us with personal data limits, that could be annoying. I did that once, forgot to disconnect and it used like 2gb (of monthly 8gb) performing sync “over WiFi”.
And Apple cares about this problem you can tell because the WiFi off button now only lasts 24hr before automatically turning back on (to avoid data waste).
I hope they don’t only focus on some minor app bugs, but also address the big giant elephant in the room : speed has been going down in a dramatric fashion release after release since ios 7.
There’s one word i wish i’d seen and haven’t so far : refactoring.
That seems a lot less useful than a functional search for messages. I hate the fact that I can only search for 1 instance of my search within a conversation. There's no way to go to a previous or next instance from the instance that the search feature already found. That sucks.
This! The Mac Messages app has the same UI for search and its possible to jump between the found messages using a keyboard shortcut. Makes me wonder if the functionality exists in iOS too but someone forgot to build it into the UI.
I agree, but perhaps a functional search is asking for too much. I'd be happy with either. If you don't have a good key word to use, then jumping to a date range is the next best thing.
Honestly, this sounds like the kind of niche feature that leads to bloatware. I can’t imagine hardly anyone would use this often, and really hope they don’t add it.
This would not be necessary if search weren’t awful, but as is they need to do one or the other. The inability to look for multiple instances of a word in a single conversation is insane.
The smartphone market isn't fiercely contested anymore IMO.
The features that Android and iOS offer are very similar. I am still very annoyed that I can't make my iPhone X automatically increase ringer volume when it gets out of range of my home WiFi (read: when I get out) while I can do that on my Android (with automation apps) but truthfully, such complaints are 3-4 at the most and I barely even notice the annoyance (at least not often).
So the fierce competition is a moot point nowadays. I applaud Apple for recognizing they need to focus on quality and I hope the results will come soon.
As boring at it sounds, this is probably more important that most people think. The "just works" mentality of iOS/Apple products is the key factor for keeping it in our family ecosystem.
Just last night, I tried my damnedest to print an IRS PDF form online. Printer's on, wifi is the same as my Thinkpad, printer is visible to laptop, etc. Nothing worked. Print was "offline" for the print queue. Just pulled out my phone, searched for the form name, opened the pdf and hit "Print" from the share screen. It's always worked, and did perfectly again. That's the greatest thing about it.
I didn't want to debug. I do enough of that shit at work.
I wonder if the mixed reviews of iOS 11 have led them to do such major overhaul. Say if iOS was responsibility of one software dev team, and they recently hired a new project manager to overlook iOS 11 development and release then I would definitely transfer that PM somewhere else in the corp along with QA guys.
For example that bug "typing the letter 'I' autocorrects to an 'A; with a unicode [?] symbol instead" might not be that big of a deal, but as we all noticed how such minute change had drastic ripple effect in entire Apple's ecosystem.
Being customer obsessed is what this implies in my mind. "The renewed focus on quality is designed to make sure the company can fulfill promises made each summer at the annual developers conference and that new features work reliably and as advertised..."
They should start by getting rid of Swift and all their proprietary APIs. Xcode is a never ending exercise in frustration. Their storyboard UI builder is even worse. And API's are constantly being deprecated and "best development practices" constantly changing.
> They should start by getting rid of Swift and all their proprietary APIs.
Swift is open source, and parts of Foundation are as well. As for their UI design toolkit, you can't possibly expect them to match that of their competitors, right?
> API's are constantly being deprecated and "best development practices" constantly changing.
Believe it or not, but writing apps in a 32-bit C API (Carbon) may not be the best way to do it. Modernization is crucial to making your platform better.
Yeah, but you get releases where I could hard lock the OS by plugging/unplugging an HDMI monitor approx 20 times (7 MBPs bought over the course of 3 months in late 2014; 3 different brands of HDMI monitor) and that's the only way you can make sense of someone letting a bug like that out the door.
What originally made the iPhone unique and powerful was that it included a full blown web browser, in the form of the Safari app. Steve Jobs announced the iPhone as a "Phone," "iPod," and "Internet Communicator."
The name "Internet Communicator" indicates how different it is from the other two apps. The Phone and iPod functionality are really a subset of the Internet Communicator.
And because the future is open web technologies, not propriety platforms like iOS, Apple should move towards that world by making advanced PWA (Progressive Web Apps) the future of all apps on iOS.
It will make installing apps on your phone as safe and easy as bookmarking a web site. It will be much closer to an optimal experience for users and developers. It's the future and Apple should be first.
Interestingly, Steve Jobs's vision for apps on iOS was essentially PWAs. He was forced to back down after developer found their way around these restrictions (i.e. jailbroke) and realized they could write much higher quality, faster, and more efficient apps natively.
Your argument doesn't really make sense: GUIs made a lot of software accessible to the average user, while web apps does nothing of the sort. To the end user, there are almost no benefits to using a web app; they're slower (yes, computers have gotten faster. That doesn't mean that the gap between web apps and native ones doesn't exist), they less accessible, they look worse, and they can't do half the things because they need to run in a web browser. The only benefits are for the developer since they don't have to spend time figuring out how to write native code for a handful of platforms and can now just write software for the lowest common denominator.
The success of the GUI shows why computing is not driven by concerns over efficiency. PWAs being less efficient than native apps is completely irrelevant. What matters is functionality.
Most apps do nothing that requires being native at all. The fact that PWAs have been implemented badly so far does not mean that there's anything inherently ugly, slow, or less accessible.
Apple could go as far as they want in making PWAs and native apps feel completely identical. They could even go as far as enforcing style, performance, and accessibility rules for PWAs.
The benefit of moving to PWAs are many and the downsides are all solvable.
> Apple could go as far as they want in making PWAs and native apps feel completely identical. They could even go as far as enforcing style, performance, and accessibility rules for PWAs.
But they have gone as far as they want, you should be happy then, or do you mean as far as you want? And isn't one of the points of web apps to not be enforceable by any single entity?
> The benefit of moving to PWAs are many and the downsides are all solvable.
Solvable only with hundreds of millions of dollars of investment and many many years of development. On second thought, they've had all that and are still not even close.
Basically, Steve Jobs didn't want developers spoiling his phone with native apps as they did on Mac OS X. However, it quickly turned out that the native apps could do a whole lot more than the glorified web apps he was proposing, and this quickly led developers to figure out ways to run native code on-device. Apple, seeing the tide turning against it, created the iPhone OS SDK in an attempt to put a modicum of control on the process.
This is the version of history I believe too, but the SDK documentation was so good that people wonder(ed) if they were planning to release it after all, maybe not for the "sell on Apple Store, we get 30% cut" developer market, but for the big software companies.
It's incredible how many people became millionaires because of them, e.g. the makers of Angry Birds. Or makers of apps like Tinder or Uber.
That’s definitely not what made the iPhone unique. It was one benefit, but hardly the only one, or even the main one.
You hope that open technologies are the future, but it remains to be seen.
Regardless, a rapid shift to PWAs is not at all in Apple’s interest, and I highly doubt they’re going to do that.
They want all the best apps, developers, and customers to be concentrated on iOS. That’s how things are now (I’m sure many will disagree), and making it easier for users to exit the Apple ecosystem will only hurt them. Apple’s strategy is to invite users into a high-quality, comprehensive ecosystem, and then sell them more devices (and increasingly services) over time. The best way to do that is to provide a differentiated experience that can’t be replicated elsewhere.
Given that, why on earth would they shift to focus on PWAs over increasing their hold on the factors that differentiate them?
You think Apple needs lock-in to keep customers but it doesn't. That's how Microsoft operates.
Apple should move to PWAs because they're better technology than native apps. Users and developers would prefer PWAs if they were well implemented, which is all Apple needs to know.
I think this is the more interesting point around which we should have this discussion.
https://www.reddit.com/r/apple/comments/7x0eif/how_apple_pla...