How Apple Plans to Root Out Bugs, Revamp iPhone Software
bloomberg.com
bloomberg.com
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...
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).
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.
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.
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 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.
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.
[1] https://twitter.com/patrickwardle/status/953416156802703360
Until you don't (see High Sierra and the "empty root password" fiasco).
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.
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, they criticized it for having stability issues and overall sluggishness https://en.wikipedia.org/wiki/IPhone_OS_2
> iPhone 3G users reported performance and battery issues after upgrading to iOS 4 https://en.wikipedia.org/wiki/IOS_4
> 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
A lot of iOS9 issues received media attention: https://en.wikipedia.org/wiki/IOS_9#Problems
https://en.wikipedia.org/wiki/IOS_10#Problems
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)
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).
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.
What you describe is a problem occurring independent of the way changes are merged. I agree that it can be a real problem.
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.
That is an extreme outlier. If your organization is run by someone like Linus, it can work, maybe.
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.
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.
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.
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).
"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."
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.
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.
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.
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.
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.
Sounds like really healthy practice
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.
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]
[1] https://twitter.com/stevesi/status/963142502604779520 (via Gruber)
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.
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.
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 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.
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.
> I think it also forced Apple's hand on FaceID
Woud you care to elaborate?
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.
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.
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.
Settings -> Developer Options -> Drawing
There are various settings there for animation styles and speeds, including 0 speed ( none ).
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.
It's cool to see other Apple engineers and PMs chime in with their perspective.
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.
> 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.
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.
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.
Is this supposed to sound bad? Because it just sounds... 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.
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 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.
> Engineering managers assign projects to engineers
So engineers do only work on tasks handed down to them. We just did not agree on what "task" means.
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.
https://www.quora.com/What-is-the-role-of-an-engineering-pro...
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.
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).
Too many downloads for a joke... Maybe drug dealers use it?
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 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.
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.
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.
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.
Isn’t this the crux of the issue? You spend big money on an iPhone/Mac and you’re left crossing your fingers as to whether it will work.
My I-devices have worked flawlessly to date, but I understand the frustration.
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.
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.
My next phone I'll take a long look at Android.
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.
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").
Maybe things have calmed down now that both platforms have X, Y, and Z.
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.
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.
That's not a code quality problem.
Teams. Whoever thought a Slack clone needed threads, should never work in a UX team ever again.
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.
[1] Microsoft employee
https://developer.microsoft.com/en-us/microsoft-edge/platfor...
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.
God this bug makes me angry.
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.
Relieving to learn that Apple tries to get back into shape again!
Marco was right:
https://marco.org/2015/01/04/apple-lost-functional-high-grou...
(By its name, High Sierra ought to be an optimization of Sierra also, but its bugginess suggests otherwise.)
Consumers and shareholders like cell phones because they're shiny.
https://www.engadget.com/2018/01/23/apple-homepod-no-mutli-r...
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!
Most people I know are already happy with the functionality of their iOS or Android devices.
"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".
Real world objects come in different sizes, so i don’t see what the problem would be in having screens that look like objects having different sizes.
https://gigaom-com.cdn.ampproject.org/ii/w680/s/gigaom.com/w...
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?
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).
e.g.: https://imgur.com/a/jYE9M (reminders is a built-in app but apparently Spotlight's never heard of it)
This has interrupted my workflow enough that I started to look for alternatives to Terminal.
More quality assurance and testing would be welcomed.
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.
https://thomas-witt.com/auto-connect-your-ios-device-to-a-vp...
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.
There’s one word i wish i’d seen and haven’t so far : refactoring.
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.
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.
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.
I hope they will not fall in that pattern.
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.
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.
So either these PWA's are slightly different than web sites, or Apple works hard to expand OS APIs that are accessible via modern web browsers.
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?
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.
Given the UI/UX of both models, I will keep using native apps whenever possible.
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.
Many people said GUIs were too inefficient to be worthwhile on early PCs. Then PCs got more powerful and no one says that any longer.
The iPhone 8 is orders of magnitude more powerful than early versions. The world has changed and those old arguments no longer make sense.
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.
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.