Using the xcode gradle sync plugin add the Kotlin source files in groups inside the XCode project. This forces the script to be run everytime a Kotlin source file is created or moved.

Instead, I suggest creating Folder References on the XCode project pointing to the commonMain and iOSMain in the Kotlin project. This allows debugging in the same way in Xcode, and ensures that the sources are always being up to date.

Special notice : be careful not to add the folder reference to the target, otherwise all your Kotlin sources will be exported in your .ipa bundle.

Install Xcode 15.0
I used build (15A5195l) - beta 4
Launch Xcode-beta
Xcode immediately crashes
run xcode-kotlin uninstall and Xcode-beta runs as expected.

I am running on an M series MBP with macOS 13.4.1 (c).

It would be nice if we could get basic stats. I'm not sure we want to do this, though, so I'm adding the task but we'll icebox it for now.

The README is old and has a lot in it. I think it can be cleaned up:

Manually installing and updating the plugin can go in a different doc. The README should assume you're using the cli.

The "sources" discussion, and anything related to that can go in a different doc. I don't want to hide our roots, but main README should be pretty clean.

Same with "Future Stuff"

I think the update/repair should go right after install. Sort of go through the tool first, then go through using the plugin. There's a conflict there. What would the user likely do first vs keeping related topics together? Because the process of adding source is a little tricky, I think that needs to be expanded. The section on the cli can be shorter, so we can at least do install and repair in one block.

There's another ticket #65 for videos. The basic usage video should be the quick start instructions.

Still thinking through it, but I'd like to try the reformat.

I did everything described in Readme
Now I'm able to use breakpoints but not able to use "po" statement or see an object state when code execution stopped at a breakpoint inside my common code.

Kotlin.ideplugin, Kotlin.xclangspec, Xcode.SourceCodeLanguage.Kotlin.plist are in the right place. Tried to reinstall the plugin but got the same issue.

Does it work as expected? I use Xcode 11.2 GM, macOs 10.14.4, KotlinNative 1.3.71

Just testing

There are issues debugging, like trying to put a breakpoint in suspend functions, or trying to step through a big recursive chain. Also simple things, like how to add source files to Xcode without adding them.

Sort of a "getting started" with debugging KN.

Running the process without args does nothing. We should print something. Probably just basic help.

How can I jump to definition, XCode 12

For people who want to use the old install (if they exist), we should create a branch before merging that a user can checkout and run the older setup.sh install. We won't be updating it, but I'm sure non-zero people won't want to run the installer for some reason.

It's possible we'll get a number of people who don't want to use the install cli, for whatever reason, in which case we should pull the setup script back and allow both, but I doubt that'll be much of an issue. Should direct people to start a discussion if so.

I've recently upgraded from Xcode 12.3 to 13.1 and the debugging and syntax formatting is no longer working for me. I've tried re-running the setup script and re-importing my kotlin folders with no success. Has anyone else experienced this?

We don't even mention that the CLI is written in Kotlin anywhere, so a building section is probably a good place to highlight that.

Xcode 11 required installing scripts where Xcode was installed. Before and after 11, the files can be installed at ~/Library/Developer/Xcode. I don't know if there is more than one of those folders if there are multiple versions of Xcode installed. If somebody has multiple versions of Xcode (I usually do, but apparently not today), see if there are multiple directories under ~/Library/Developer/.

Add Kermit to the cli tool, and have it log to memory (see #60). When a report is sent, it'll pull the logs and send them.

As part of Kermit install, add logging around major events.

• User input (install, repair, etc)
• Any file operations
• Any user input. That includes shutting down Xcode (y/n), and anything else

There's not a lot going on in the tool, so I'm not sure how much logging we'll need, but it would be good to get some trail of what the user was doing in case there are issues.

Does anyone know if it is possible to extend Xcode's code completion capabilities beyond Swift/Objective-C? I have not done much research on this, but the fact that lldb integrations are possible at least makes the question seem worth asking.

In any case, if someone here is able to indicate that this is not a complete fool's errand, I'd be happy to run a spike on it and see where it goes!

• has-reproduction
• feature
• blocking
• good first issue

It should maybe say something about not being installed, but not just crash.

The install process is not great. Explore homebrew install.

How to make one is not super clear. Here's a place to start: https://docs.brew.sh/Formula-Cookbook

Most users we'll get to the page will be used to the current install. Add a "what's new?" section.

• Homebrew install and update
• Local repair on Xcode updates
• Better diagnostic info if there are issues

Xcode 13.3.1 (13E500a) crashes on startup M1 Max MBP running macOS 12.3.1.

Attempted simply rerunning ./setup.sh to reinstall, but it did not solve the issue.

Solution was to remove the plugin from ~/Library/Developer/Xcode/Plug-ins and the spec from ~/Library/Developer/Xcode/Specifications. Xcode then opened successfully. Ran xcode-kotlin's setup.sh to reinstall. Xcode opens successfully.

Summary

With xcode-kotlin installed via Homebrew, Xcode 14.3.1 was crashing on every launch attempt after I updated to macOS 13.5.

Details

Here's the relevant portion of a crash log that led me to suspect an Xcode plugin.

Process:               Xcode [6765]
Path:                  /Applications/Xcode-14.3.1.app/Contents/MacOS/Xcode
Identifier:            com.apple.dt.Xcode
Version:               14.3.1 (21815)
Build Info:            IDEFrameworks-21815000000000000~2 (14E300c)
Code Type:             ARM-64 (Native)
Parent Process:        launchd [1]
User ID:               502

Date/Time:             2023-07-24 20:21:03.4225 -0600
OS Version:            macOS 13.5 (22G74)
Report Version:        12
Anonymous UUID:        98E02397-17E1-FC60-7879-5861D2741E7C


Time Awake Since Boot: 870 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000

Termination Reason:    Namespace SIGNAL, Code 6 Abort trap: 6
Terminating Process:   Xcode [6765]

Application Specific Information:
abort() called


Application Specific Signatures:
_mutableDirectExtensions != ((void *)0)

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	       0x18aafc764 __pthread_kill + 8
1   libsystem_pthread.dylib       	       0x18ab33c28 pthread_kill + 288
2   libsystem_c.dylib             	       0x18aa41ae8 abort + 180
3   IDEKit                        	       0x107433220 +[IDEAssertionHandler _handleAssertionWithLogString:assertionSignature:assertionReason:extraBacktrace:] + 980
4   IDEKit                        	       0x107433660 -[IDEAssertionHandler handleFailureInMethod:object:fileName:lineNumber:assertionSignature:messageFormat:arguments:] + 872
5   DVTFoundation                 	       0x103dd5c40 _DVTAssertionHandler + 424
6   DVTFoundation                 	       0x103dd5dc0 _DVTAssertionFailureHandler + 196
7   DVTFoundation                 	       0x103e1c3d0 -[DVTExtensionPoint _registerExtension:] + 296
8   DVTFoundation                 	       0x103c4b55c -[DVTExtension awakeFromPropertyList] + 176
9   DVTFoundation                 	       0x103c84e50 -[DVTPlugIn awakeFromPropertyList] + 384
10  DVTFoundation                 	       0x103db44e4 -[DVTPlugInManager _createPlugInObjectsFromScanRecords:] + 328
11  DVTFoundation                 	       0x103db2a78 __52-[DVTPlugInManager _recordNonApplePlugInDescriptor:]_block_invoke + 92
12  DVTFoundation                 	       0x103db3040 -[DVTPlugInManager _allowNonApplePlugInsFromDescriptors:error:] + 304
13  DVTFoundation                 	       0x103db3228 -[DVTPlugInManager _checkNonApplePlugIns] + 204
14  DVTFoundation                 	       0x103db3304 -[DVTPlugInManager initializePlugIns:] + 20
15  IDEFoundation                 	       0x108ad2e74 _IDEInitializeOtherPlugInStuff + 168
16  IDEFoundation                 	       0x108ad51b0 IDEInitialize + 4968
17  IDEKit                        	       0x107417dcc -[IDEApplicationController applicationWillFinishLaunching:] + 484
18  CoreFoundation                	       0x18ac07180 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 148
19  CoreFoundation                	       0x18aca2eec ___CFXRegistrationPost_block_invoke + 88
20  CoreFoundation                	       0x18aca2e34 _CFXRegistrationPost + 440
21  CoreFoundation                	       0x18abd84cc _CFXNotificationPost + 704
22  Foundation                    	       0x18bb368e4 -[NSNotificationCenter postNotificationName:object:userInfo:] + 88
23  AppKit                        	       0x18de2b1bc -[NSApplication finishLaunching] + 248
24  DVTKit                        	       0x102d82f94 -[DVTApplication finishLaunching] + 196
25  AppKit                        	       0x18de2aea8 -[NSApplication run] + 252
26  DVTKit                        	       0x102d82e08 -[DVTApplication run] + 60
27  AppKit                        	       0x18de023cc NSApplicationMain + 880
28  dyld                          	       0x18a7dbf28 start + 2236

Reproduction

I haven't performed these steps as such, I'm proposing how you would set up the situation I found myself in.

1. Install Xcode 14.3.1 on macOS 13.4.1.
2. brew install xcode-kotlin
3. Xcode should launch successfully.
4. Update to macOS 13.5.
5. Attempt to launch Xcode.

Expected result

Xcode launches successfully.

Current state

Xcode crashes immediately, before any of its windows are shown. Holding down Option-Shift while launching does not fix the problem, so it's not due to opening the projects that were open when you last ran Xcode.

Possible Fix

The problem was fixed for me by brew uninstall xcode-kotlin.

Screenshots

None.

Issue Labels

• has-reproduction
• feature
• blocking
• good first issue

Hello. I'm new to developing a Kotlin project with Xcode.

It seems there are no recent commits or releases for this repository.

Can I still use this plugin for Kotlin Multiplatform development on Xcode?

We talked about building a version that doesn't require locally building the CLI. I'd like to follow up with that discussion. I'd very much rather avoid that for the general user. What's involved and how do get that ball rolling?

Create a Kermit logger that stores logs, so we can have a breadcrumb trail of what happened. This would just get stored in memory. I don't expect we'll have much to track, so this doesn't need to be very optimized.

Wrap the main function. If anything throws, ask the user if we can report it (y/n), then create a log file with the exception and the breadcrumb trail. We can add a simple POST endpoint to the Faktory API/Spring server and push these into an S3 bucket. I'd suggest chronological naming to make it easy to see by time.

This will only be usable at low traffic, which is what I would expect for quite some time. Eventually we may want to bump this up to a proper crash reporter, which can group crashes by stack trace.

I think we should set debug build to always upload. Release build should ask. Discuss!

Not-real issue. Trying out Zenhub integration

We should add a CLI that would get installed using Homebrew. There's two ways we could make it work and we should decide which one is better.

Bundled mode

In the bundled mode, the plugin files are included with the CLI binary when downloaded by Homebrew. Installing the xcode-plugin formula would automatically put the plugin to the right place. The CLI would then have a single purpose, to update the DVTPlugInCompatibilityUUIDs entry in the plugin's Info.plist file.

1. Running xcode-plugin repair [xcode path,...]
   a. Loads UUIDs of all currently installed Xcodes and those provided manually.
   b. Updates the DVTPlugInCompatibilityUUIDs entry in the installed plugin.
2. Running xcode-plugin repair --only [xcode path,...]
   a. Loads UUIDs of only the Xcode paths provided manually.
   b. Updates the DVTPlugInCompatibilityUUIDs entry in the installed plugin.

When new changes to the plugin, users would run brew upgrade xcode-kotlin which would perform the same steps as the initial install, updating both the installed plugin and the CLI.

Independent mode

In the independent mode, the plugin files live in a separate repository from the CLI. It's up to additional discussion whether the plugin would be installed during the CLI's installation by Homebrew.

The plugin would then have the following features:

1. Running xcode-plugin install [version] (xcode-plugin update would do the same)
   a. Downloads the latest plugin (or the version specified) from GitHub repository.
   b. Loads UUIDs of currently installed Xcodes and updates the DVTPlugInCompatibilityUUIDs plist entry.
   c. Copies the modified plugin to the plugins folder
2. Running xcode-plugin repair [xcode path,...]
   a. Loads UUIDs of currently installed Xcodes and those provided manually.
   b. Updates the DVTPlugInCompatibilityUUIDs entry in the installed plugin.
   c. Fails if the plugin is not installed yet.
3. Running xcode-plugin repair [xcode path,...]
   a. Loads UUIDs of only the Xcode paths provided manually.
   b. Updates the DVTPlugInCompatibilityUUIDs entry in the installed plugin.
   c. Fails if the plugin is not installed yet.

It's old. Pulling it. Adding an issue to see how zenhub handles these things...

Explore being able to step into Kotlin from calling code (Swift/Objc). I'm pretty sure this isn't possible, but it's something we should explore.

See Slack for some context: https://kotlinlang.slack.com/archives/C3PQML5NU/p1654805821671169

While the DVTPlugInCompatibilityUUID seems to be included in the Plugin Plist, (A74FBA51-FFEA-4409-B976-6FC3225A6F64), Xcode does not seem to approve of that Plugin. Upon Clicking "Load Plugin", Xcode quits, and upon new launches, it will display the dialog to load the plugin, but then immediately quit without the plugin.

I am using master@aa6bfba

Not sure exactly why, but sometimes the pointer isn't valid. I'm not sure if this is for any data, just arrays, or whatever. The old "check" method would simply skip over invalid pointers. That may be fine, but I'd like to understand what's actually happening.

When lldb and Xcode loop through a set of fields, we get calls for both regular named fields and ampersand prefix fields, which is presumably some form of "address of". I'm not sure why, and both our support and the original python formatter skipped them. We should do some research and figure out what they're for.

The sync process creates all folders it finds, even if there is nothing in them. We should avoid creating folders when there's no data in them.

I ran brew install xcode-kotlin first and then when I run xcode-kotlin install I get following (crash report hopefully uploaded short while ago) . This is M1 device fwiw. Currently have Xcode 13.4 installed.

Installing 1.2.0.
xcode-kotlin has crashed, do you want to upload the crash report to Touchlab? y/n: y
Uploading crash report.
Upload successful

The word "Xcodes" is used in a few places (README and code), but should be more like "Xcode installations".

I'd like the team to try this out. Hopefully we can find any significant bugs before release.

I think we can merge to main before testing, but I don't want to be out in main too long before we announce.

So far the plugin has worked great for me, but I think there is an opportunity to make it even smoother. I have a Kotlin/Native project that generates an xcframework which I then pull in via swift package manager. When I have the Kotlin/Native project locally and registered as a Folder Reference in XCode it works great, but on a new machine where I don't have the original repo synced I cannot easily add breakpoints. Because SPM is based on the git repo it already is syncing all of the .kt files associated with the xcframework. Is there an easy way to make the plugin have access to these files? It would make it much easier for an iOS developer to debug the internals without needing a lot of additional steps.

The files get synced to
/Users/username/Library/Developer/Xcode/DerivedData/Packagename-byqdevosfmstyigxngorlffhsqub/SourcePackages/checkouts

Hey folks,
My team has been using this plugin reliably for a year or so but recently we've found when we set breakpoints in our shared Kotlin code and press run the breakpoints turn to the dotted blue outline state indicating that the code is never executed/compiled - it definitely is getting executed!

We've tried uninstalling and reinstalling the plugin through the CLI as well as reinstalling with Homebrew but with no luck. We've also reimported the folder references to the shared code in our Xcode project too.

Interestingly the KaMPKit sample project breakpoints perfectly fine. Any ideas on how to resolve?

Details

xcode-kotlin info

Installed plugin version:	1.2.1
Bundled plugin version:		1.2.1

Language spec installed: Yes
LLDB init installed: Yes
LLDB Xcode init sources main LLDB init: No

Installed Xcode versions:
✔	Xcode 14.2 (14C11a)	C91F3560-00E7-4749-8E3F-4D83B1496051	/Applications/Xcode.app

In addition we've also made sure our preprocessor macros for debug is set to: DEBUG=1.

Expected result

Breakpoints get triggered when code is executed.

Current state

Xcode is indicating that the code is never executed.

Screenshots

Rust lldb formatters seem to support much more formatting and may produce much better type info in the debugger. The lldb docs aren't easy to parse, so looking at the rust sample should tell us a lot: https://github.com/vadimcn/vscode-lldb/blob/master/formatters/rust.py

The speed of the debug is very slow ? any advice ? my xcode version is 11.6 (11E708)

Should make some installation and usage videos.

• Video installing the cli, then installing the plugin. Show the Load Bundle and explain
• Video adding source, and debugging. Explain that source built on different machines won't work in the debugger
• Video upgrading Xcode

It would seems as though the latest update to xcode, 12.3, has broken support for xcode-kotlin. I've tried removing and reinstalling the plugin. When booting xcode, I no longer get the prompt to load the plugin bundle.

Hi!

I've installed plugin from CLI, added iosMain and commonMain as it's suggested in video tutorial

I observe crashes in my release build in iOS, and for some reason I see kotlin files in stack trace, and I can set breakpoints

Debug build doesn't allow to set breakpoints at all.

Output of xcode-kotlin info:

`Installed plugin version: 1.2.1
Bundled plugin version: 1.2.1

Language spec installed: Yes
LLDB init installed: Yes
LLDB Xcode init sources main LLDB init: No

Installed Xcode versions:
✔ Xcode 13.2.1 (13C90b) 7A3A18B7-4C08-46F0-A96A-AB686D315DF0 /Applications/Xcode.app

✔ - plugin is compatible, x - plugin is not compatible
Run 'xcode-kotlin sync' to add compatibility for all listed Xcode versions.`

I've seen how files in filetree look like on the video (with Koltin icon), it's not like that for me:

I've checked KaMPKitiOS project and it's working fine.

This project is big, its main contributor has left and I need to make some support fixes for it. Also I'm not very experienced mobile developer but I have been writing some backend/web development for several years.

Thank you for any help!

Summary

We use the lldb script that ships with Kotlin, which hasn't changed in many versions. It has changed with 1.9 fairly significantly.

Details

We use the same lldb script as Kotlin. In the past, we've had a lightly modified script, for optimizations. I'm not sure if our last script was 100% stock or not (I think it was, but it has been some time). We need to take the script from 1.9.0, put it in the plugin, and test that building with 1.9.0 works for debugging.

Then, assuming that works, we should get a sense of performance. If the debugging works OK, we can just move forward, and maybe add another task to look into performance. If it's bad, or doesn't work at all, we'll need to dig deeper.

After everything works, we'll need to release a new version of the install tool. We don't currently support multiple Kotlin versions with the tool, mostly because the lldb script hasn't changed in a long time. We'll probably need to have the "install" process somehow be able to distinguish versions. Should discuss a design of this after we test that 1.9 works.

To get the plugin to work after upgrading Xcode, several people have had to completely remove the files and reinstall them. This should be verified and added to the setup process.

The kotlin native debug support saves string values in a place marked by Konan_DebugBuffer(). Not sure how often lldb will need to be thread safe, but it'll fail if multiple threads try to use the buffer.

Various reports have come in that Xcode 15 does not work. Xcode 15 is still in beta, so this may not be an issue, but we are always at the mercy of Apple and what they plan to shut down as far as Xcode extendability. We should try this out and see if we can sort out issues.

There are things that are missing in the readme. Maybe should make a video too. Along with #47 Homebrew install, this should make install and maintenance easier.