Post not yet marked as solved
Confirmed after testing on my side, the HLS / m3u8 video (not appearing) bug described in this thread is fixed and longer an issue with Xcode 15 beta and Simulator 17.
Thank you, Apple Developer Tools team.
Post not yet marked as solved
(And here's what was filed with Feedback-Assistant ID# FB12264845)
Xcode 14.3 and Simulator 16.4 HLS/m3u8 video playback issue
Please see the following thread:
https://developer.apple.com/forums/thread/727288?login=true&page=1&r_s_legacy=true#754122022
This BUG REPORT is in response to a conversation earlier via WWDC Lab ID 7873788389, i.e. reporting the bug described in the above forum feed, and as follows:
HLS video is no longer playing beginning with XCode 14.3 and in Simulator 16.4.
I've isolated example code below. Note that .mp4 video plays fine, however HLS/m3u8 video does not (stream loads but only audio plays).
This bug is only in the Simulator (16.4); i.e. on device (and in previous Simulators) m3u8 video plays fine. Please see the forum thread for more details and other developer reports.
Thank you.
Example code:
/* Supporting includes, variables, etc.
#import <AVFoundation/AVFoundation.h>
#import <AVKit/AVKit.h>
@property (nonatomic, strong) AVPlayer *player;
@property (nonatomic, strong) AVPlayerViewController *playerViewController; */
// Initialize AVPlayer
// .mp4; note mp4 plays fine, i.e. video appears.
//NSURL *videoURL = [NSURL URLWithString:@"https://commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4"];
// m3u8; note HLS/m3u8 VIDEO DOESN'T APPEAR, however file "successfully" loads and e.g. audio plays.
NSURL *videoURL = [NSURL URLWithString:@"https://bitdash-a.akamaihd.net/content/sintel/hls/playlist.m3u8"];
self.player = [AVPlayer playerWithURL:videoURL];
// Initialize AVPlayerViewController
self.playerViewController = [[AVPlayerViewController alloc] init];
self.playerViewController.player = self.player;
self.playerViewController.view.frame = self.view.bounds;
[self.view addSubview:self.playerViewController.view];
// Play the video
[self.player play];
Post not yet marked as solved
I have a 1on1 WWDC lab session scheduled @ 2PM PT today with a member of the XCode team, and hope to get us all participating in this thread more clarity on the issue. Will report back here later today.
Post not yet marked as solved
Interestingly, the pixels from an HLS stream are available in the 16.4 Simulator(s), i.e. it's possible to get a valid (loaded w/ the video frame and not black) CVPixelBufferRef from the stream, even though video won't display on screen.
Att: Apple, please hurry up with a fix on this! It makes developing streaming video applications a pain i.e. not being able to actually program and text the latest OS on anything other than connected devices (rendering the Simulators pretty much useless for developing our application).
Post not yet marked as solved
We're discussing this same issue over here too:
https://developer.apple.com/forums/thread/727288
Post not yet marked as solved
Same issue in all 16.4 Simulators, HLS video is black, audio is fine.
Tested on e.g. 14.1 simulators and the video plays as it should. What's weird is this (16.4 simulators) was working fine until today and I'm pretty certain I've not updated since a few weeks ago (all automatic updates are off).
Post marked as Apple Recommended
Same purple security warning in Xcode 14 (latest release) here.
"This method should not be called on the main thread as it may lead to UI unresponsiveness."
In my case I've traced it to a WKWebView -> loadRequest:, i.e. called from my main ViewController's -> viewDidLoad:
i.e. I load a web view at app startup, as after launch/splash screen it's the first view user will see. I'm careful about accounting for network issues and will timeout (or not even try loading), display an alternative screen, etc. if there are network issues.
I'm going to assume someone on the Xcode team chose to add this warning in the event a developer doesn't account for slow loading or not loading at all an initial wkwebview when the app first launches?
Any other theories? Is it safe to ignore the warning?
Post not yet marked as solved
Same purple warning in Xcode 14 here.
"This method should not be called on the main thread as it may lead to UI unresponsiveness."
In my case I've traced it to a WKWebView -> loadRequest:, i.e. called from my main ViewController's -> viewDidLoad:
I load a web view at app startup, as after launch/splash screen it's the first view user will see. I'm careful about accounting for network issues and will timeout (or not even try loading), display an alternative screen, etc. if there are network issues.
I'm going to assume someone on the Xcode team chose to add this warning in the event a developer doesn't account for slow loading or not loading at all an initial wkwebview when the app first launches?
Any other theories? Is it safe to ignore the warning?
Post not yet marked as solved
Same purple warning in Xcode 14 here.
"This method should not be called on the main thread as it may lead to UI unresponsiveness."
In my case I've traced it to a WKWebView -> loadRequest:, i.e. called from my main ViewController's -> viewDidLoad:
I load a web view at app startup, as after launch/splash screen it's the first view user will see. I'm careful about accounting for network issues and will timeout (or not even try loading), display an alternative screen, etc. if there are network issues.
I'm going to assume someone on the Xcode team chose to add this warning in the event a developer doesn't account for slow loading or not loading at all an initial wkwebview when the app first launches?
Any other theories? Is it safe to ignore the warning?
Same purple warning in Xcode 14 here.
"This method should not be called on the main thread as it may lead to UI unresponsiveness."
In my case I've traced it to a WKWebView -> loadRequest:, i.e. called from my main ViewController's -> viewDidLoad:
I load a web view at app startup, as after launch/splash screen it's the first view user will see. I'm careful about accounting for network issues and will timeout (or not even try loading), display an alternative screen, etc. if there are network issues.
I'm going to assume someone on the Xcode team chose to add this warning in the event a developer doesn't account for slow loading or not loading at all an initial wkwebview when the app first launches?
Any other theories? Is it safe to ignore the warning?
Post not yet marked as solved
Same.
Thought it was on my end
and wasted a few hours removing and reinstalling certificates and provisioning profiles.
Would be nice if Apple's Status web page actually reflected these issues with an accurate status )-:
Post not yet marked as solved
Same issue, re: iPhone mini 12;
I get screen dimensions of 375x812 (x3) reported in the Simulator.
Whereas the actual device dimensions are 360x780 (x3).
This basically renders it impossible for me to account for iPhone mini 12 as you've said without having a physical device.
Post not yet marked as solved
Same issues as everyone else, i.e. recently migrated to M1 MacBook Air and paste no longer works in iOS 15.4 Simulator.
I downloaded 13.7 simulators as suggested, paste works in 13.7 but now (in 13.7) certain kinds of videos (streams) refuse to load.
Xcode 13.3; running in Rosetta mode (using some libraries e.g. AFNetworking that aren't yet updated/supported w/ new M1).
Any new insights into (fixing?) this issue appreciated.
Post not yet marked as solved
Also experiencing these issues (slow typing, slow navigation) with XCode13.
Albeit, my app is incredibly complex, multiple files, many containing thousands of lines of code.
But XCode is a professional tool, and hasn't given me this kind of grief in the decade using it to build for the Apple eco system.
If this continues it may finally push me away from Apple development and move my work to "web applications" instead.
PS Unchecking Preferences->General->Show Live Issues helped but didn't completely solve the slowness issues for me.
Post not yet marked as solved
A couple. of threads about this.Currently Apple's status page still shows an issue with the TestFlight service, but no explanation and no ETA as to when it will be fully resolved.
