T-Mobile’s 5G network is now up and running in several US cities. This initial phase of the carrier’s 5G strategy uses the same sort of high-frequency millimeter wave network tech as Verizon, resulting in download speeds that far exceed what LTE phones can reach today. The biggest problem with millimeter wave is range: to cover a whole city, you need to have 5G nodes — the things that beam out the millimeter wave signal — all over the place. In Verizon’s case, things are still spotty. As I keep saying, 5G speeds are there on one street and gone the next. Walls and windows are also fatal for millimeter wave, so it doesn’t extend indoors.
T-Mobile says it will overcome these challenges by augmenting the millimeter wave side of its 5G network with low-band 600MHz spectrum. The latter won’t offer the same mind-blowing download rates, but low-band spectrum covers much more ground and can actually make it into buildings.
T-Mobile and Sprint are pushing for their merger so hard, partially because they believe they’ll be able to build a best-in-class 5G network by combining the best of their spectrum assets. (Sprint is currently rolling out 5G right overtop its LTE network and offers far more extensive coverage than its rivals because it’s not using millimeter wave.)
But let’s talk about how T-Mobile is doing out of the gate: pretty good. Below is a sample of the 5G speeds that I saw on T-Mobile around New York last Friday. Disregard the “LTE” icon to the left of each test, as the bulk of these were done on 5G; the Speedtest app just doesn’t yet recognize that. As you can see, the peak speeds are about half as fast as the best tests I got in Chicago when trying out Verizon’s network. But it’s still a clear jump from LTE when you’re in that 400 / 500 Mbps range. I downloaded Spider-Man: Into the Spider-Verse in about two minutes at “high” video quality from Netflix. A long Spotify playlist of over 100 songs took 15 seconds to finish up at “extreme” audio settings. In real world scenarios — even before it aids self-driving cars and makes cloud gaming more responsive — 5G will prove convenient in a pinch when you need to download something in a hurry before a flight or underground train. (Uploads, however, are still using only the 4G network for now, as is also the case with other carriers.)
It’s not winning at speed, but for now, T-Mobile can at least claim that it’s faring a little better at coverage. The carrier’s map would have you believe it’s done an impressive job of blanketing sections of New York with 5G. My real-life experience didn’t quite match that. In sections of the Financial District of Manhattan near The Verge’s office, I’d see the 5G indicator but get typical LTE download speeds. On other streets where T-Mobile’s map glowed pink to indicate 5G coverage, the phone only displayed 4G when downloading content from Netflix or Prime Video.
I saw T-Mobile’s 5G nodes on top of many smaller buildings scattered around Manhattan. And it did pay off: the Samsung Galaxy S10 5G held on to 5G on the move noticeably better than it did on Verizon’s 5G network in Chicago. I didn’t feel as though I had to freeze in place whenever I found a 5G signal to get those speedy downloads. But I’m not sure how accurate this coverage map is...
There’s one wild card here: it was an extremely hot day in New York City on Friday, with a high temperature of over 90 degrees. Samsung designed the Galaxy S10 5G to fall back to 4G LTE whenever it gets overheated. Running multiple back-to-back speed tests and downloading entire movies is a surefire way to warm up a 5G device. So I can’t be sure whether some of the situations where I only saw 4G when I was expecting 5G were due to the network or the phone itself.
Rubbing the S10 5G on my iced coffee helped keep it cool, but it was a rough environment for testing a phone. Unfortunately, Samsung limited press to just a few short hours with the device, even though it’s available in stores right now. As a result, we all walk away with an imperfect view of T-Mobile’s early 5G network — even if T-Mobile itself admits this is only stage one. It’s off to an impressive start in New York, though the patchy nature of millimeter wave is more evident when you look at T-Mobile’s other launch markets like Las Vegas and Dallas. Not great.
T-Mobile past buildout investments in NYC are paying off for the first round of 5G deployment, but elsewhere, the carrier is facing the same there-and-gone-again challenges as Verizon. Even if you’re in NYC, buying the Galaxy S10 5G on T-Mobile seems a little silly. It’ll only ever be able to take advantage of that millimeter wave part and won’t support the 600MHz 5G band when T-Mobile starts rolling that out later this year. Other phones coming in the second half of 2019 should be optimized for both, but I still think we’re at a place where your next phone upgrade won’t (and shouldn’t) be a 5G device. Your phone after that is a different story.
Owners of OnePlus 7 Pro phones have randomly received several weird notifications, causing consternation and concerns about security.
The two alerts, which showed up on phones on Monday morning, were strings of Chinese characters and random letters, as first reported by The Verge. When users tapped on the notifications, the phone would receive an error message saying "browser not found."
Many OnePlus 7 Pro owners took to Twitter to question the strange notifications and whether they represented a security issue.
OnePlus confirmed the issue in a tweet and insisted it was not a security breach but an accident caused by internal testing. "During an internal test, our OxygenOS team accidentally sent out a global push notification to some OnePlus 7 Pro owners," the company tweeted. "We would like to apologize for any difficulties, and assure you that our team is currently investigating the error."
There are no further details yet on what caused the error, but users can rest assured that it was a minor mistake.
Enlarge/ Twitter returns to the Mac via Apple's Project Catalyst.
Apple
SAN JOSE, Calif.—When Apple revealed macOS Catalina at WWDC this month, one related announcement drew considerable interest from Mac users and developers alike: a new way to turn iPad apps into fully native Mac apps.
Dubbed Project Catalyst, it promised to increase the number of quality native apps on the Mac platform by leveraging developers' existing work in the arguably more robust iOS (and now, iPadOS) app ecosystem. But it does raise questions: what does this mean for Mac users' future experiences? Will this change the type of software made for Macs? Is Apple's ecosystem a mobile-first one?
Then there are developer concerns: is Catalyst just a stepping stone to SwiftUI? What challenges can devs expect when adapting their iPad apps for the Mac?
Ars spoke with key members of the Apple team responsible for developing and promoting Project Catalyst, as well as with a handful of app developers who have already made Mac apps this way. We asked them about how Catalyst works, what the future of Apple software looks like, and what users can expect.
The Mac is a popular platform among developers, creatives, and beyond. But while the iPhone and iPad App Store have thrived as one of the industry's most vibrant software ecosystems, the Mac App Store hasn't gained the same level of traction or significance, despite the presence of powerful applications that are not available on mobile.
Apple seeks to funnel some of its success with the iOS App Store over to macOS using Catalyst. We'll go over how developers use what Apple has built step-by-step, as well as what challenges they faced. And we'll share Apple's answers to our questions about how the company plans to maintain a high standard of quality for Mac apps as an influx of mobile-derived apps hits the platform, what Apple's long-term plans for cross-platform apps across the entire ecosystem look like, and more.
Before we get started, here's a list of the Apple representatives and third-party app developers we spoke with for this deep dive:
Todd Benjamin, Apple's senior director of marketing for macOS
Ali Ozer, Apple's Cocoa engineering manager who worked on the Catalyst project
Shaan Pruden, Apple's senior director of partner management and developer relations
Manu Ruiz, an engine software engineer at Gameloft who worked on bringing the iPad game Asphalt 9: Legends from iPad to Mac
Alex Urbano, a graphics engineer at Gameloft who also worked on the Mac version of Asphalt 9: Legends
Rich Shimano, an iOS developer at TripIt, a travel app that was brought natively to the Mac using Catalyst
Nolan O'Brien, Twitter's senior staff software engineer who used Catalyst to bring Twitter back to the Mac
Bloomberg reported way back in December 2017 that Apple was working on a project that would make developing apps for both macOS and iOS side-by-side easier. We learned at WWDC this year that one major component to that push is called Project Catalyst, which enables porting iPad apps to the Mac relatively quickly.
App developers can start doing this now with the beta version of Xcode, the development environment Apple maintains for making apps for its various platforms. To much fanfare on the WWDC stage, Apple claimed developers simply need to open their iPad app project in Xcode and click a single check box to be able to build a Mac app. Of course, it won't always be quite that simple—but it's closer than you might think.
Apple's new framework, Project Catalyst, will help iOS developers translate existing mobile apps into macOS apps.
Much of Project Catalyst's work begins in Xcode.
Apple also introduced a new cross-platform UI framework called SwiftUI.
The idea is to handle some of the difficult aspects of porting a mobile app to the desktop—like moving from a touch-based interface to a mouse-pointer-based one—automatically and quickly so developers can jump right into adding desktop-specific features where desired.
Here's what Apple's developer site says about it:
Mac app runs natively, utilizing the same frameworks, resources, and runtime environment as apps built just for Mac. Fundamental Mac desktop and windowing features are added, and touch controls are adapted to the keyboard and mouse. Custom UI elements that you created with your code come across as-is. You can then continue to implement features in Xcode with UIKit APIs to make sure your app looks great and works seamlessly.
Note that this is not emulation we're talking about; Apple instead sought to make it possible to build native applications for both the Mac and the iPad from the same Xcode project.
Apple dedicated multiple sessions at WWDC to educating developers on its efforts and what it considers to be the best practices for adapting iPad apps for the desktop. Todd Benjamin, senior director of marketing for macOS, explained to Ars why Apple has decided to make this a priority now:
We're at a stage at this point now where developers have fully developed iPad apps, and there's a great opportunity to take the work that they've done there, which not only leverages what they had done on iOS, but also takes advantage of screen space and some things that we can leverage nicely as we bring them over to the Mac.
Senior director of partner management and developer relations lead Shaan Pruden added:
[Developers'] customers had been asking them for a Mac version because they have a big install base on the iPad, and they just didn't feel like they had the wherewithal to spin up a whole other development team and do a port.
And why go from iPad to Mac instead of the other way around? "We have millions of apps out there for the iPad," Apple Cocoa engineering manager Ali Ozer, who worked directly on making Catalyst a reality, told Ars. "So there's a direction which makes more sense, at least when it comes to enabling developers."
Critically, bringing iPhone apps over to macOS is not what Catalyst does—they have to be iPad apps. This might seem surprising: the iPhone has one of the most robust software ecosystems in the world, whereas the iPad is mostly a subset of that. There are some iPad apps that aren't on the iPhone, yes, but there are countless iPhone apps that aren't on the iPad.
Benjamin said Apple made that decision because it's a more natural transition to bring an app from the iPad over to the desktop than it is to adapt an iPhone app over:
Just design-wise, the difference between an iPad app and an iPhone app is that the iPad app has gone through a design iteration to take advantage of more screen space. And as you bring that app over to the Mac... you have something that's designed around that space that you can work with and that you can start from.
Ozer noted that the move is also about pre-empting user concerns about mobile ports spilling into the desktop even though the ports aren't appropriate for the platform. "This is one way of making developers aware that an iPhone app in its current form might not be the right design," he said.
How it works
Many of the frameworks developers use to create apps for the iPad and the Mac are similar. Part of what Apple did here was bridge the differences that previously existed between the iPad and Mac versions of shared development frameworks. But the biggest gap is that between the UI frameworks.
Developers build user interfaces and functionality of iPad apps using the UIKit framework. Meanwhile, the Mac has a framework called AppKit that does many of the same things. Previously, Mac apps could not run apps made using UIKit, and iOS devices could not run apps made using AppKit. Even if a developer could reuse some pieces of their iPad apps when building Mac versions, doing so took a considerable amount of additional work.
The Catalyst process starts, as Apple is very keen to point out, by clicking a single checkbox.
An illustrative example of the macOS and iOS stacks side-by-side. Apple could already run the iOS stack on the right on the Mac in Xcode's simulator. But the simulator wasn't designed or optimized to integrate with the rest of the Mac UX.
Here's a list of deprecated frameworks Apple recommends leaving behind when bringing iPad apps to the Mac. While some deprecated frameworks may work on the iPad for a while yet, developers can't count on them working on the Mac.
When viewing their iPad project in Xcode, a developer can check a box to select the Mac as a supported device. After that's done, Xcode makes the following changes to the project, according to Apple's documentation:
Adds a bundle identifier for the Mac version of your app.
Adds the App Sandbox Entitlement to your project. Xcode includes this entitlement in the Mac version of your app, but not in the iOS version.
Adds My Mac to the list of destinations that you can choose when running your app from Xcode.
Excludes incompatible frameworks, app extensions, and other embedded content.
Barring any errors, the developer should then be able to deploy a basic version of their app for the Mac. The following Mac-specific features should automatically be part of the new Mac version, Apple says:
A default menu bar for your app.
Support for trackpad, mouse, and keyboard input.
Support for window resizing and full-screen display.
Mac-style scroll bars.
Copy-and-paste support.
Drag-and-drop support.
Support for system Touch Bar controls.
From this point, the developer can add menu-bar items, apply translucency to the primary view controller, display and populate a preferences menu, add hover events, and so on.
Some frameworks are available on one platform but not another—for example, ARKit is not available on the Mac, so a developer porting an app that uses ARKit to deliver augmented reality experiences will want to consider that. In some cases, code pertaining to features and frameworks not present on the target device will automatically not be used.
In other instances, developers can, of course, use conditional logic in their code to deliver different experiences and functionality based on which device the software is running on. Apple, however, intended for that approach to be reserved for cases where functionality is simply not available on a certain device but is desired on another.
"We'd like them to use conditionals as little as possible because, you know, conditionals are different code paths that you have to worry about," explained Ozer. "And I think that the things we've tied to conditionals are APIs and features that are really very much Mac-only."
Apple says that many of the developers building the first third-party Catalyst apps managed to get an acceptable build running on the Mac within 24 hours. But each faced some challenges unique to each app.
If you got a strange OnePlus 7 Pro push notification on Monday, you're not alone. Owners of the Chinese phones rushed to Twitter to express their concerns over a pair of garbled messages -- one of which appeared to be Chinese characters and other in the Latin alphabet.
Trying to follow the link apparently resulted in a "browser not found" message. The issue is seemingly only affecting the OnePlus 7 Pro, which came out in May.
"During an internal test, our OxygenOS team accidentally sent out a global push notification to some OnePlus 7 Pro owners," the company wrote in response.
Its team is investigating what happened and the company promised to share more details "soon."
Now playing:Watch this:
Tips and tricks for the OnePlus 7 Pro
2:03
OxygenOS is a customized version of Android developed by OnePlus and the odd notification caused some people to worry about the security of their data, harking back to a 2017 incident where a security researcher found that personal data was being sent to OnePlus servers.
It responded by explaining how people could opt out of data collection and promised to stop gathering data like "telephone numbers, MAC addresses and Wi-Fi information."
First published at 2:46 a.m. PT. Updated at 3:23 a.m. PT: Adds more detail.
About an hour ago, OnePlus 7 Pro users got pinged with two weird notifications on their devices, emanating from OnePlus's own Push service. One of them had a string of gibberish latin consonants and the other what appears to be Korean or Chinese characters. Users were obviously confused and thought this was spam or the servers were hacked, but OnePlus has just cleared things up saying it was an error originating from a test.
According to the company, this happened during an internal test and the notifications were sent out globally to OnePlus 7 Pro owners. If you were awake, you were probably surprised by the mysterious message — some users found it funny, others thought it was spam, and a few were alarmed that their phones or OnePlus' servers might have been hacked. If you were asleep, I hope you had your phone on DND, because I definitely don't want to be awakened in the middle of the night by an "hbgchjvgchjg" message. Sentient technology is the stuff of nightmares, and my doozy state might lead to panic for a few seconds at the sight of that message.
During an internal test, our OxygenOS team accidentally sent out a global push notification to some OnePlus 7 Pro owners. We would like to apologize for any difficulties, and assure you that our team is currently investigating the error. We’ll share more information soon.
But all's well now. OnePlus says it's investigating the error and will share more information as soon as it's identified the reason this happened. Hopefully the company puts an "are you sure you want to send this to thousands of people worldwide?" double check in its testing system.
If you've been considering a Fire TV Recast, now is the time to buy - the DVR is on sale for its lowest price ever. From today, the Recast is on sale for $129.99, a saving of $100.
The compact box offers both DVR and streaming features, giving cord cutters an option to watch network TV content and sports broadcasts as well as streaming services like Netflix or Hulu. You can watch over-the-air-TV from channels like ABC, CBS, FOX, NBC, PBS or the CW or record shows to watch later. There's also Alexa integration and you can use the device with your mobile device (iOS and Android) as well as Fire TV, Echo Show or Fire Tablet.
The deal comes in the lead-up to Amazon's Prime Day, which is actually two days this year on July 15th and 16th. It's also in advance of National Cut the Cord Day on July 7th, when streaming companies offer deals to tempt viewers away from their cable TV packages.
Ask iPhone users about the creature comforts they like and there's a good chance they'll mention AirDrop -- it's an easy way to share a photo with a nearby Apple device owner. Android users should soon have an equivalent, though. The 9to5Google team has managed to enable an upcoming Fast Share feature on Android that, like AirDrop, would use a combination of Bluetooth and WiFi to send files and even text snippets to nearby people. Turn it on and you can see nearby Fast Share-enabled devices, with transfers taking just a couple of taps (including a confirmation from the recipient).
There are a few key differences. It doesn't appear that you can limit transfers to your contacts, but you can specify "Preferred Visibility" so that favorites see you even when you're not using Fast Share. The sample recipients in the Fast Share screen suggest this might be available on Chromebooks, iOS devices and even Wear OS smartwatches, although we wouldn't count on all of those being available whenever the feature goes public. An iOS version would require a special app.
It's not certain when Fast Share will launch, although it's a Google Play Services feature and likely wouldn't require Android Q. Google might not wait long, though. The company has warned that it's deprecating NFC-based Android Beam transfers in Q. As such, Fast Share could be the only way to quickly send files to local users without resorting to apps (like Files by Google) that your friends won't necessarily have.
:format(webp):no_upscale()/cdn.vox-cdn.com/uploads/chorus_asset/file/16684641/DSCF2069.jpg)
:format(webp):no_upscale()/cdn.vox-cdn.com/uploads/chorus_asset/file/16684133/IMG_2917.jpg)
:format(webp):no_upscale()/cdn.vox-cdn.com/uploads/chorus_asset/file/16684813/Screen_Shot_2019_06_28_at_5.40.28_PM.png)
:format(webp):no_upscale()/cdn.vox-cdn.com/uploads/chorus_asset/file/18272331/371057F0_F04E_4118_A77D_7CE81CDED2D0.jpeg)
:format(webp):no_upscale()/cdn.vox-cdn.com/uploads/chorus_asset/file/16684704/DSCF2072.jpg)
