Sony is closing Firewalk Studios, the studio behind its PlayStation Concord game that it took offline last month after a disastrous launch. In a message to PlayStation staff, Hermen Hulst, CEO of the PlayStation studio business group, says Firewalk Studios will close alongside Neon Koi, a mobile game studio. The shutdowns will affect about 210 jobs, Bloomberg reports.
“We have spent considerable time these past few months exploring all our options,” says Hulst. “After much thought, we have determined the best path forward is to permanently sunset the game and close the studio. I want to thank all of Firewalk for their craftsmanship, creative spirit and dedication.”
Hulst says Concord didn’t hit Sony’s targets and that the PlayStation maker will “take the lessons learned from Concord and continue to advance our live service capabilities to deliver future growth in this area.”
Concord debuted on August 23rd on both PS5 and PC, but Sony took the game offline on September 6th after poor sales of the game. Estimates have put sales at under 25,000, and Concord only managed to hit an all-time peak of just 697 players on Steam, lower than the launch peak of The Lord of the Rings: Gollum.
Firewalk is signing off one last time.
Firewalk began with the idea of bringing the joy of multiplayer to a larger audience. Along the way we assembled an incredible team who were able to: - Navigate growing a new startup into a team during a global pandemic: Firewalk was…
Sony’s Neon Koi mobile game development studio is also shutting down, despite Hulst saying “mobile remains a priority growth area.” Sony originally acquired the German-Finnish studio when it was known as Savage Game Studios in 2022, and the team was working on an unannounced triple-A mobile live service action game.
“With this re-focused approach, Neon Koi will close, and its mobile action game will not be moving forward,” says Hulst. “Both decisions were given serious thought, and ultimately, we feel they are the right ones to strengthen the organization.”
Some of the impacted developers may find roles within Sony’s other studios, but the rest will join the thousands in the game industry that have been laid off over the past couple of years.
Update, October 29th: Added Bloomberg’s reporting about how many jobs were impacted.
"I want to thank all of Firewalk for their craftsmanship, creative spirit and dedication." That's why we're shutting down the studio and firing all of you. Thank you!
Spotify claims Apple may again be in violation of European
regulation, the Digital Markets Act (DMA), which requires
interoperability from big technology companies dubbed
“gatekeepers.” This time, the issue isn’t about in-app purchases,
links or pricing information, but rather how Apple has
discontinued the technology that allows Spotify users to control
the volume on their connected devices.
When streaming to connected devices via Spotify Connect on iOS,
users were previously able to use the physical buttons on the side
of their iPhone to adjust the volume. As a result of the change,
this will no longer work. To work around the issue, Spotify iOS
users will instead be directed to use the volume slider in the
Spotify Connect menu in the app to control the volume on connected
devices.
The company notes that this issue doesn’t affect users
controlling the volume on iOS Bluetooth or AirPlay sessions, nor
users on Android. It only applies to those listening via Spotify
Connect on iOS.
Who should get to decide the rules for how the hardware volume buttons work on iPhones and iPads? Apple, or the European Commission?
Much like a Mac keyboard the currently active app should decide what the buttons do. If Apple can use them as shutter buttons in Camera other apps should be able to use them too. Also, according to the last paragraph Spotify does support Airplay, but who has time for reading when a a government is meddling with Apple's buttons.
New cars that are sold in Europe from this week will host
automatically-installed speed limiters, following the introduction
of a new EU law.
Even though the rule to install the technology does not apply in
the UK, many of the cars will have been made in Europe and so will
feature the Intelligent Speed Assistance (ISA) anyway.
The technology allows the car to automatically restrict its speed
based on GPS location, speed-sign recognition and cameras within
the vehicle. This is not done simply by applying the brakes, which
could be dangerous, but by gradually reducing the engine’s power.
However, drivers will first get a warning that they are driving
too fast and be told to slow down before the measure takes affect.
When a friend sent me this link, I thought at first that LBC was some sort of Onion/Babylon Bee-style parody site. But no, this is real. Any politician in the U.S. seeking to end their career should propose similar legislation here.
In the EU, drivers will be able to turn off the system every time
they start their car. It cannot be permanently shut off.
I take back my complaint that the EU no longer innovates in technology. They brought the EU cookie-consent web experience to cars. Nonstop pointless nagging and annoyance.
Speaking of nifty new Safari extensions from Christian Selig, Achoo is an iOS 15 Safari extension that gives you a good “View Source” command for inspecting (and editing) the code for any web page. $1, cheap!
There is, it's called "Web Inspector", it's in the App Store. There is also SourceWeb but the inspector itself lives in an external app which doesn't always connect properly to its extension.
The design of Safari 15 on the iPhone has gone to a better place, but Stephen Hackett reminds us that trouble on the Mac and iPad remain:
The ordering of the UI elements at the top of the screen… divorces the tab — which includes the name of the current webpage — from the webpage itself. Maybe everyone at Apple prefers their bookmarks in the Sidebar instead, but for those of us who are used to the more traditional location, having the Favorites Bar split the tab and its content makes skimming what tabs are where more work than it should be.
To make matters worse, it’s hard to tell at a glance which tab is active and which is inactive. Previous versions of Safari didn’t struggle with this, but Apple has seem to fit to bring the age-old “which iPad app has focus” problem to the browser. Using the Monterey beta, I almost always end up trying to tab to or away from the wrong tab because I can’t quickly register which one is active when looking at the tab bar.
I think Apple has improved the legibility of the selected tab a bit in recent betas, enough that it’s usable, but it’s not as good as it could be.
As to the placement of the Favorites Bar — there’s really no excuse. It breaks the entire metaphor of tabs by placing non-tab-specific content beneath tabs, and divorces the tabs from the URL bar. I’d like to believe that this is a design oversight that Apple will correct at some point, but my fear is that Apple simply doesn’t think the Favorites Bar is a relevant feature in a world where you can browse your favorites from a Safari Start Page.
I like the Start Page a lot, and on the iPad I frequently navigate to favorite sites via the Start Page. But on the Mac I use the Favorites Bar all the time. It’s a valid and valuable Safari feature, and it deserves better than the bad placement it has in the current Safari 15 betas.
If you can’t move the preferences window because it’s fake, you might be running an Electron app like 1Password 8.
I’ve used AgileBits’s 1Password for more than a decade. I’ve recommended it to friends and family alike. Over time, password management has become more common, and this fall’s operating-system updates will improve Apple’s built-in password management so much that it’s all most people will ever need.
That said, 1Password offers many features Apple doesn’t, and the company has become increasingly active in competing in the enterprise space, with an influx of investment to help it grow rapidly.
Which brings us to this week, when AgileBits announced the beta version of 1Password 8 for the Mac—and walked into a storm of criticism from Mac users. You see, AgileBits chose to build the new version of its Mac app using Electron, a system based on web technologies that’s used by numerous cross-platform apps, including Slack, Skype, and Discord.
I think it’s fair to say that most users don’t care about the tools that a developer uses to write the apps we use. But using a system like Electron does have consequences: Electron apps have a reputation for being slow, eating up a lot of system memory, and—perhaps most offensively—failing to behave like proper, “native” apps on whatever platform they operate.
Just as there are good and bad Catalyst apps, there are good and bad Electron apps. I’m sure that the very best Electron app isn’t as good a Mac app as one written using Apple’s AppKit frameworks—but that doesn’t mean that it can’t be good. And AgileBits has pointed out that it’s using Rust, a robust programming language, to power everything except the user interface, so performance should be more than you’d expect from “just a web app.”
I’m going to withhold judgment of 1Password 8’s interface, mostly because it’s still in beta and I’m sure AgileBits is going to get plenty of feedback about all the ways it fails to measure up to the standards of Mac users. I hope they’re listening and will adjust accordingly.
What’s really causing all this consternation, I think, isn’t 1Password moving to Electron. Electron is a bit of a bogeyman. The root problem is this: 1Password, originally a Mac-forward software developer, has simply decided that the Mac isn’t important enough.
I know that those are harsh words, and that the people at AgileBits would argue with them. But in a blog post by Michael Fey, AgileBits’s VP of Engineering for Client Apps, the company laid out its entire development strategy. It’s a post meant to explain what the company is up to and tamp down a lot of angry hot takes (and probably should’ve been posted the moment it announced the Mac beta).
Fey’s post clearly spells out AgileBits’s priorities. Android and iOS apps are built with native platform frameworks in order to create the best app experience possible on mobile. For iOS, AgileBits decided to use Apple’s new SwiftUI framework rather than the venerable UIKit, in order to skate “to where the puck was going.” Their plan was to use SwiftUI on the Mac, too. In doing so, AgileBits was buying into the vision Apple has for SwiftUI as a tool to build interfaces across all of Apple’s platforms. Unfortunately, it seems that SwiftUI didn’t measure up on the Mac:
Despite the fact that SwiftUI allowed us to share more code than ever between iOS and macOS, we still found ourselves building separate implementations of certain components and sometimes whole features to have them feel at home on their target OS.
I have to read this as a (gently stated) indictment of the current state of SwiftUI. AgileBits was willing to put in the extra work for iOS, because it’s an important platform and SwiftUI is clearly the future there. But implementing it on the Mac required a lot of duplicate work—and what’s worse, SwiftUI apps aren’t compatible with older versions of macOS. AgileBits was planning on covering the older versions with an Electron version, but once it decided the SwiftUI implementation for the Mac was too much work, it pulled the plug—and now plans to ship an Electron version to all Mac users.
I appreciate that AgileBits was originally planning two separate Mac implementations. That’s a sign that the company cared enough to expend extra resources to have a good experience on the Mac, rather than doing what it did to Windows users in deciding Electron was good enough.
And yet as a longtime Mac user, I find AgileBits’s decision-making process incredibly sad. Because as Fey’s post makes clear, at no point did the company consider keeping the Mac-only version of 1Password alive. AgileBits, once a major Mac developer, decided (for legitimate business reasons, of course) that the Mac’s not a platform that deserves its own bespoke app. Or as Fey put it:
We could support as many versions of macOS as we wanted using Apple’s AppKit framework, but that meant adding another frontend toolkit to the mix.
Translation: The Mac’s important, but not important enough to build a version of the app that only works there.
I get it. 1Password has to cover Mac, Windows, Android, iOS, and the web. The Mac is a small platform compared to Windows, and “desktop” is a small platform compared to “mobile.” If I were an engineering manager asking for resources for a bespoke Mac app, I would have a hard time justifying it, too.
And yet, here we are. A banner Mac app and app developer has abandoned a platform-native app for the same web-app wrapper it’s using on Windows. Even if it’s the best Electron app you’ve ever seen, it won’t be the same—and more than that, it says something painful about the future of Mac software.
Apple shares the blame, though. If today’s SwiftUI was truly the One True Tool to unify Apple’s platforms that it’s meant to be in the future, the Mac version of 1Password would be presented in SwiftUI. And perhaps in a year or two, that will happen—after all, the SwiftUI version of 1Password is right over there on iOS, ready to make the move when it’s feasible.
Just because these are decisions made with the cold, hard reality of business priorities and budgets and the current state of developer tools doesn’t make me any less sad, though. A long-running and beloved Mac app is getting thrown in the trash and replaced with a web app. It’s not the first—and unfortunately, it won’t be the last.
Log in
