DTiPhoneSimulatorErrorDomain Code 2

Yes and this is also not the first beta. We developer know this already from former iOS betas. After 1-2 betas the battery drain and performance is again like it should be.But nearly all of us use the devices also private. The battery of the watch was much better than older phones. Now it is so worse that you can use the watch only for development and put it then on the charger. And I am also a little bit worried if this is good for the battery also when it needs so much energy in such a short time. Maybe someone can give us some information why the watch needs now so much battery power even without using native apps.

Same here. But yes this is noted in the release notes. I think in two weeks with Beta 2 it will be fixed.

The init changed, the code that fixed the issue is this oneinit() { super.init(frame: CGRectZero, style: UITableViewStyle.Plain) initialize() } required init(coder aDecoder: NSCoder) { super.init(coder: aDecoder) initialize() } init(frame: CGRect) { super.init(frame: frame, style: UITableViewStyle.Plain) initialize() } override init(frame: CGRect, style: UITableViewStyle) { super.init(frame: frame, style: style) initialize() }

I had the same issue with battery drain on day one - after 7 hours I had only about 10% battery. But I used Siri about more than 10 times and scribbled a little bit.Today on day two I had more than 70% battery left after 6 hours - which is quite good :-) The first hour I was all the time on 100% then it droppped to 99% which I was asthonished about :-p But i didn't used Siri or Scribbles just read notifications I recieved, checked the time and used navigation for 5 minutes.Don't know if the difference is just because of Siri and Scribble or maybe some setup processes were in background on day one.Let's see how the battery is draining the next days.

Yup, so the crash log isn't really useful on its own.I recommend you put breakpoints into your code, run it and step over line by line and see exactly the lines where it crashes. We can't do that for you, you have to do it. Have a look in the Apple debugger documentation if you don't know how to do it. In my experience, crashes in my code on arm64 have been regular bugs in the code that caused memory access issues that didn't crash on armv7 but do crash on arm64. But they were still bugs. In some situations they didn't crash on the simulators but do crash on real devices. Run using the debugger on real devices if you can.

Hi,seeing the same thing here. Also tried to delete all podcasts by removing them from the sync in iTunes. I haven't tried to reinnstalling, but attached is the crash-log.Incident Identifier: B5F20F2E-F1DF-469D-B710-8DEE3DC9104BCrashReporter Key: fb29f236715284e01c3ca12533f80c13bbf8eb99Hardware Model: iPhone7,2Process: Podcasts [425]Path: /Applications/Podcasts.app/PodcastsIdentifier: com.apple.podcastsVersion: 967.2 (2.3)Code Type: ARM-64 (Native)Parent Process: launchd [1]Date/Time: 2015-06-10 13:18:56.56 +0200Launch Time: 2015-06-10 13:18:55.55 +0200OS Version: iOS 9.0 (13A4254v)Report Version: 105Exception Type: EXC_CRASH (SIGABRT)Exception Codes: 0x0000000000000000, 0x0000000000000000Exception Note: EXC_CORPSE_NOTIFYTriggered by Thread: 7Filtered syslog:None foundLast Exception Backtrace:0 CoreFoundation 0x182f93f44 0x182e6c000 + 12122281 libobjc.A.dylib 0x197faff2c 0x197fa8000 + 325562 CoreFoundation 0x182f93e8c 0x182e6c000 + 12120443 Foundation 0x183e10f0c 0x183e04000 + 530044 Podcast