Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-23786] iOS10: Logs not working on iOS 10 devices.

GitHub Issuen/a
TypeBug
PriorityCritical
StatusClosed
ResolutionFixed
Resolution Date2016-10-17T17:45:32.000+0000
Affected Version/sRelease 5.5.0
Fix Version/sRelease 6.0.0, node-ios-device 1.0.0, ioslib 1.0.0
ComponentsiOS, Tooling
Labelsnotable, qe-5.5.0, qe-6.0.0
ReporterJosh Longton
AssigneeChris Barber
Created2016-08-17T16:45:55.000+0000
Updated2017-01-05T15:04:02.000+0000

Description

Steps to reproduce:

Use the environment above.

Create a new project appc new

Use the app.js below.

Run the application and click the button on the screen

App.js

{noformat} var win = Ti.UI.createWindow({ backgroundColor: 'white', exitOnClose: true, fullscreen: false, layout: 'vertical', title: 'ERROR' }); var button = Titanium.UI.createButton({ title: 'Click', top: 50, width: 100, height: 50 }); button.addEventListener('click',function(e) { Ti.API.info("########### Info"); Ti.API.warn("########### Warn"); Ti.API.error("########### Error"); }); win.add(button); win.open(); {noformat}

Actual

No logs are shown after: {noformat} [TRACE] : ** BUILD SUCCEEDED ** [INFO] : Finished building the application in 14s 652ms [INFO] : Installing app on device: Eggs [INFO] : App successfully installed on device: Eggs Please manually launch the application [TRACE] : updating tiapp metadata with Appcelerator Platform... [TRACE] : Uploaded tiapp metadata with Appcelerator Platform! {noformat}

Expected

This is what the iPhone 6 iOS 10 simulator shows: {noformat} -- Start simulator log ------------------------------------------------------- [WARN] : ########### Warn [INFO] : ########### Info [ERROR] : ########### Error [TRACE] : updating tiapp metadata with Appcelerator Platform... [TRACE] : Uploaded tiapp metadata with Appcelerator Platform! {noformat}

Attachments

FileDateSize
app.js2016-10-11T07:25:09.000+00001874

Comments

  1. Josh Longton 2016-08-17

    Logs will appear if I run the application using debug.
  2. Hans Knöchel 2016-08-17

    Could be an open Xcode 8 issue (see [here](https://forums.developer.apple.com/thread/49323)). {quote} When debugging an app running on Simulator, logs may not be visible in the console. Workaround: Use command + / in Simulator.app to open the system log in the Console app to view NSLogs. (26457535) {quote} *EDIT*: Wait, so it does work in sim? Can you also check if you have the jscore flag enabled?
  3. Josh Longton 2016-08-17

    Yes sim worked and I do not have the jscore flag.
  4. Hans Knöchel 2016-08-19

    Might be a Xcode 8 issue: http://stackoverflow.com/questions/37886600/ios-10-doesnt-print-nslogs
  5. Eric Wieber 2016-09-01

    I can also reproduce this issue. However, in light of what Hans said, should this be resolved as "not our bug"?
  6. Chee Kiat Ng 2016-09-08

    Tested with Xcode 8 GM and logs are working. resolving as not our bug.
  7. Caio Perdona 2016-09-09

    This is CRITICAL and we're having this issue since 5.2.0.GA. It is EXTREMELY DISAPPOINTING as we cannot debug on the device.
  8. Ketan Majmudar 2016-09-13

    I can't see logs on Sim or Device running ios10 for apps built with 5.4.0.GA (Ti SDK) using Xcode 7 (SDK v9.3) We have a bug that needs to be resolved, we need logging to do this.
  9. Ketan Majmudar 2016-09-13

    For now, (as we are using a custom logging function wrapped around the Ti.API logging) i have modified this to write all the log levels out to a flat file using Ti.Filesystem , which I can review in the iOS Simulator file structure. It's better than nothing. Actually found the iOS 10 issue i was looking for straight away.
  10. Hans Knöchel 2016-09-13

    This issue is currently being investigated. It is caused by a major Xcode 8 issue that changed the whole logging- and debugging-system of iOS-apps. That's why many native apps currently run into the same issue. We thought Apple will provide a suitable fix for the GM but they didn't, so we are searching for a better way. Keeping this ticket updated.
  11. Caio Perdona 2016-09-16

    @Hans Hi Hans. Any update on this issue?
  12. Chris Barber 2016-09-16

    [~perdona] I'm actively working on this. I've got a solution, but it's going to take some time to fix. We have to do quite a bit of work on both the Node.js build tooling and the iOS platform code. Please watch this ticket for updates.
  13. Caio Perdona 2016-09-16

    @Chris Barber Hi Chris. I'll keep tracking this ticket, thanks for the feedback!
  14. Brian Freid 2016-09-20

    Can someone please provide an update on this ticket? Do you have an ETA of when this might be resolved?
  15. Chris Barber 2016-09-20

    [~bfreid] This ticket is in progress. It will be fixed for Titanium SDK 6.0.0. Please watch this ticket to track the progress. Once it has been fixed, you can download and install an unstable CI (continuous integration) build or wait until 6.0.0 ships.
  16. Jason Kneen 2016-09-20

    Those facing this issue (including native developers), there's a workaround if you're running macOS Sierra -- the new console app can be used to select a device that's plugged in, and using filtering you can filter by process and see real-time logs.
  17. Tim Poulsen (ACV) 2016-09-20

    LemonJar's iOS Console is also useful http://lemonjar.com/iosconsole/ Logs are noisy now. But you can filter on [INFO] for example to pare down to your own console.log messages.
  18. Brian Freid 2016-09-20

    Tim Poulsen, Thank you for your help. Because of your fix to the logs we were able to track down the issues that Facebook was experiencing and resolve our issue. Thank you so much for your help and patience in this matter.
  19. Chris Barber 2016-10-10

    node-ios-device PR: https://github.com/appcelerator/node-ios-device/pull/25 ioslib PR: https://github.com/appcelerator/ioslib/pull/48 TiSDK master PR: https://github.com/appcelerator/titanium_mobile/pull/8495 TiSDK 6_0_X PR: https://github.com/appcelerator/titanium_mobile/pull/8496
  20. Chee Kiat Ng 2016-10-11

    CR and FT passed. Tested with combinations of: - iOS 10 simulators and devices. - run-on-main-thread true/false. - use-jscore-framework true/false. - put app to background and return. - with wifi / without wifi enabled on device. More scenarios to consider: - on Xcode 7.3.1. - on Alloy projects. - on Studio with live view or debugger enabled.
  21. Chris Barber 2016-10-11

    To test, create a new app and add a bunch of log calls or just use my attached app.js. Build for iOS Simulator and launch app, then: * Fire home button twice and kill the app -> logging should stop and build should exit * Kill the simulator -> logging should stop and build should exit * Background the app -> setInterval() logging should continue Build for device and launch app, then: * Tap home button twice and kill the app - logging should stop and build should exit * Unplug the device -> logging should stop and build should exit * Background the app -> setInterval() logging should pause
  22. Chris Barber 2016-10-11

    Important!

    The new logging system uses a TCP port. The port number is ALWAYS determined at build time, never at run time. This means that if you build two different Titanium apps, they cannot use the same port at the same time. There are a couple ways the tooling works to overcome this. For both simulator and device builds, the iOS build will auto-select a port between 10000 and 60000 based on the app id. For example, the app id com.appcelerator.testapp3269 will generate the port 10416. The primary reason we do this is attempt to avoid the same port being used by different apps. The other reason we do this so we don't have a different port each build and crippling differential builds. A nice side-effect is the new logging system allows multiple simultaneous clients as well as reconnects and having a consistent port is convenient. It is important to note that because we are auto-selecting a port number based on the app id, the probability of a collision is extremely high. com.appcelerator.testapp17 and com.appcelerator.testapp8249 both resolve to port 19024. This is where <log-server-port> comes in handy. You may specify a <log-server-port>XXXXX</log-server-port> in the <ios> section of the tiapp.xml and it will always be used first. Also note that the port number must be an integer between 1 and 65535 and probably should be greater than 1024 to avoid binding to a privileged port. The port number should be unique per project. You only need to use this if the auto-selected port number is causing collisions with other apps. This is really only a problem when working with multiple projects at the same time. If there is a collision where two different apps are being built AND running at the same time with the same port, the first app to launch will get the port. The second app will try to bind to it, but it will fail. It is very important to note that whichever app launches 2nd will fail to bind to the port, however the 2nd app will still continue to run normally, just without logs. For simulator builds, you can open the simulator's system.log, or for device builds, use the macOS Sierra Console application at any time to view the log messages. The biggest issue to be aware of is the 2nd app's iOS build will end up connecting to the 1st app's log server. There is currently no way for the iOS build to know which log server for which app it has connected to. In the future we may introduce a more proper protocol to handle this. For simulator builds only, the port is shared with the local machine. For example, you could use port 27017 for device builds, but you can't for simulator builds if you have MongoDB installed. So, if there is no <log-server-port>, or there is, but it's not available, or the app id-based port is not available, then the iOS build will fallback to a random port number that will certainly change every build. It's also worth noting that for simulator builds only, the iOS build will start up a Node.js server on the selected port to make sure it's available. If it isn't, it will randomly test ports until it finds an available port. To be clear, device builds do not have this limitation. The client in the iOS build that connects to the app will always connect after the app has started. This means it's possible for several messages to have already been logged. Because of this, Titanium will queue the last 100 log messages only while there are no client connections. As soon as the iOS build connects to the log server, the queue is flushed and released. This shouldn't be a huge deal since the client tries to connect every 250ms. Finally, logging is only enabled for simulator and device builds. It is NOT enabled for app store or adhoc builds. You can enable it by hacking the build system or via a CLI plugin. [~bimmel] please use the rambling above to document the behavior, limitations, and settings. Thanks!
  23. Hans Knöchel 2016-10-11

    PR's merged! The latest build (6.0.0.v20161011102836) includes the fix. It actually does much more than "just" fixing it, it also speeds up the printed logs using a TCP connection instead of watching the log-file manually. To all watchers of this ticket: Please test the new 6.0.0 build (e.g. using appc ti sdk install -b 6_0_X or download your preferred build [from here](http://builds.appcelerator.com/#6_0_X). We will most likely release 6.0.0 Beta next week that will of course also include the change. Code strong and probs to [~cbarber]!
  24. Harry Bryant 2016-10-12

    Verified as fixed, ran the above test cases on iOS Simulator and Device. Tested On: iPhone 6 Plus 10.0.2 Device & Simulator Mac OS Sierra (10.12) Ti SDK: 6.0.0.v20161012041242 Appc Studio: 4.8.0.201610060953 Appc NPM: 4.2.8-7 App CLI: 6.0.0-57 Xcode 8.0 Node v4.4.7 *Closing ticket.*
  25. Chris Barber 2016-10-13

    Reopening to assign sprint
  26. Chris Barber 2016-10-13

    Sorry for so many re-opens and closings. Jira keeps removing the sprint when this ticket is closed. Ugh.
  27. Abir Mukherjee 2016-10-14

    I understand that the Jira was reopened because the sprint info was removed by Jira, but I also verified the fix with an iOS 10 device. I first reproduced the issue with Titanium SDK version 5.5. There were no console message in Studio with 5.5. Then I retried with Titanium SDK version 6.0.0.v20161013072802, and I saw appropriate log messages. This is my environment: Device: iPhone 7 iOS 10.0.1 NPM Version: 2.15.9 Node Version: 4.5.0 Mac OS: 10.11.6 Appc CLI: 5.5.0 Appc CLI NPM: 4.2.7 Titanium SDK version: 6.0.0.v20161013072802 Appcelerator Studio, build: 4.7.1.201609100950 Xcode 8.0 GM
  28. Chris Barber 2016-10-17

    Reopening to try and assign sprint again.
  29. Petr Cervenka 2016-11-30

    Any chance this can get fixed in 5.5 branch ?
  30. Jason Squire 2016-12-08

    I am having the same issue on iOS 10 devices in the 5.5 branch.
  31. Chris Barber 2016-12-08

    [~jason.squire%40gmail.com] This was fixed in 6.0.0. Titanium 5.x and older does not support Xcode 8 and iOS 10. [~cerw] Sorry, there's no plans to backport the new logging facilities to 5.x.
  32. Raymond Verbruggen 2016-12-23

    This blocks development and updates completely! A lot of modules bought from the Appcelerator Marketplace are not supported by SDK 6 (for whatever reason???). So PLEASE either remove blocking of modules in SDK6, or backport logging to the SDK5.x development chain.
  33. Chris Barber 2016-12-23

    [~ray@raymondverbruggen.nl] iOS modules that work for Titanium 5.x should work in Titanium 6.x. I'm pretty sure it's just Android that was affected thanks to updating the V8 version. Backporting the iOS device logging is a massive amount of work and I don't see us doing that. If you upgrade to macOS Sierra, you can use the new system log tools to view the "process" logs.
  34. Raymond Verbruggen 2016-12-23

    Hello Chris, Thank you for your rapid response. I think that the amount of trouble that is caused by simply saying "appcelerator does not support ... anymore" is underestimated. It looks to me that there is only attention to OS'es new gimmicks, instead of realizing that a lot of developers have an update issue of existing apps for customers. It's a developer's nightmare to be confronted with having released apps that cannot be continued/developed/supported by newer versions of the development chain. For example see the screenshot. This is a module that is critical for several apps. The company that I bought the module from is not responding to any questions at all. Likely no 6.x update will be made available. I need to update this large app, as it looks now I must develop/buy a completely new Bluetooth module. It is from Appcelerator's side too easy to simply "not support" it. Source code is not available so updating the module is not possible by me. Didn't you think of the number of module supplier's that are confronted by having to update their modules? "Just Android that was affected"... we are talking about a multi platform development tool! You cannot simply cut off 50% of all apps! Who is going to pay for all extra cost? I cannot do that because my company is too small. What is needed is a 5.x to 6.x migration guide; what can you encounter and how can you solve it? The solution for a lot of developers in my opinion is to make 6.x support older modules!!! Otherwise it stops for us. Looking forward to hearing from you again. Best regards, Raymond
  35. Ingo Muschenetz 2016-12-23

    Hi [~ray@raymondverbruggen.nl], Please note that our primary goal here is to make sure our customers are well-supported. With this, I believe you have a number of options already. Remember that our hand is forced here as well--Apple broke its existing logging system with iOS 10, and Google breaks compatibility with new versions of Chrome. But we have to support new versions of iOS, and new versions of Chrome bring many new features and improvements.

    If you want to stick with SDK 5.X, use macOS Sierra for logging output, as Chris explained.

    If you want to upgrade to SDK 6.X, realistically, only the Android modules needed recompiling (as the Chrome interface changed). Thus, your iOS bluetooth module should continue to work.

    Our source code is open, so an interested party could backport the changes themselves.

    There is a long set of release notes here: http://docs.appcelerator.com/platform/latest/#!/guide/Titanium_SDK_6.0.0.GA_Release_Note that detail many of the changes. It's impossible to make SDK 6.0 support older modules because of the requirements of Chrome updates. If these options still do not meet your needs, please file a support ticket, and we'll see how else we can assist. Best, Ingo
  36. Ingo Muschenetz 2016-12-23

    Apologies, I meant V8, not Chrome above.
  37. Raymond Verbruggen 2017-01-05

    Hi Ingo, First of all the best wishes for 2017!! I understand what you are saying. And I understand that you are confronted with changes. My main issue is that we - as developers - need to maintain apps for customers. I choose for appcelerator already about 5 years ago, because of it's single code-base multi platform system. During the time a lot of appcelerator major updates we have been confronted with changes that need a lot of extra work. Work without adding functionality or improvements, only to keep the development toolchain up to date. The following happened: Needed to do a small quick update for a customer. No logging! Google help -> the Ti.API.info IOS10 logging issue. This one is not mentioned nor is there a compatible workaround documented. "Use macOS Sierra for logging output"... what? how? A major function is not working anymore, so a little more help than that is needed... Switch to SDK6, but some Android modules are not supported anymore. Also the given Ti.include("functions.js") workaround does not work anymore in my Alloy project (yes, it did). From alloy.js it does not include the "functions.js" file in the lib folder. Already deprecated since 3.3.0? SDK compiler 5.x still did not give a message about this. And I can surely understand that "require" is much better but there is no time for changing all that now. Lot of functions, and no right-click -> find references function in Appcelerator Studio... I hope you can understand my frustrations. Like I said, what is needed is a 5.x to 6.x migration guide; what can you encounter and how can you solve it? Instead of needing to call google for help when something is not working. Best regards, Raymond
  38. Jason Kneen 2017-01-05

    Raymond, You should be able to view logs on iOS 10 devices with your current setup using https://lemonjar.com/iosconsole/ Alternatively, you can run 5.5.1.GA (which doesn't require Android V8 module re-compiling and should be a small update from 5.4.0 given my experience with updating apps from 5.4 to 5.5) with Sierra and view using the built-in console app (which is way better than the El Capitan one). Re Ti.Include -- this was deprecated years ago and replaced with a CommonJS approach which is what Alloy is based on. Mixing CommonJS and Ti.Include isn't a good solution can lead to many more issues. It should be straight-forward as well to port your Includes to commonJS modules, which will give better isolation, and reduce the risk of performance issues and memory leaks. Ping me on Ti-Slack if you have any issues. Jason

JSON Source