⚠️ 2026 Update: This method is not 100% perfect. Since writing this post I have occasionally gotten OnStar emails from GM reporting things about the car. Isolating radio signals is hard!

Last year I purchased my first modern connected vehicle. As Mozilla has previously reported, modern vehicles capture (and sell) data about your behavior (how you drive, where you live, where you drive to, what your sexual orientation is). As such, I decided to look into the process of disabling OnStar.

Thanks to Imgur I found a way to (reversibly, not permanently) disable OnStar. In short, because OnStar will still report data back to General Motors and their data brokers even if you don't pay for OnStar (as best I can tell), the only way to truly protect your privacy is to either live in California where you can request to opt out of data collectin via the California Consumer Privacy Act (CCPA) or disable the OnStar hardware. Given that I don't live in California, I opted for the latter approach.

My thanks to BiggRanger on Imgur for originally documenting this process. I followed their instructions but still ran into some difficulty so I am re-documenting this with more information about the process.

Step 1

Purchase a FAKRA Z Jack Female to SMA Female adapter and an SMA male 50 ohm terminator. This is what will isolate the OnStar modem from the world. Screw the terminator onto the SMA plug. Ensure that it tightened fully to isolate the Bolt from the cellular radio signals.

FAKRA Z Jack adapter with terminator installed.

Step 2

Gain access to the rear of the center console by removing the glove box. Pop open the glove box and remove the damper from the right side. This required pliers to pinch the clip so that it could slide off and took more sliding force than I expected.

The glove box damper and clip.

Squeeze the sides of the glove box inward so that the plastic stops on each side no longer catch, and the glove box cavity opens up completely.

The glove box catch/stopper.

The glove box cavity.

Step 3

Identify the connector. Shine a flash light into the console and find the purple/violet connector. This is the cellular antenna connector (although this guide is for the Bolt, according the FAKRA chart, Purple/Violet is the industry color code for cellular/GSM so this could work in other vehicles too).

The FAKRA Connector Color Code Chart

The inside of the dash behind the center console from outside the glove box opening.

A closer look at the Purple/Violet FAKRA cellular connector.

The cellular connector was closest to the glove box and pretty easy to spot. I had to reach my hand in pretty far to grab it though.

Reach in there, nothing will bite.

Step 4

Unlock the connector and slide it out. This was the hardest part for me. The original Imgur post made it sound like you “just” take a “small” screwdriver and slide out red locking tab so that you can squeeze the connector and pull it off, but sliding the locking tab out of the way took me over an hour. What is small?

Turns out “small” means less than 18cm (5 inches) tall, with a very thin flat edge, 4mm (1/8th inch) wide. The electronics screwdriver set I have pictured below was just a little bit too tall to be effective, so I ended up using some “screwdriver pen” thing my wife had laying around.

This is what “small” means. The screwdriver on the right worked for me.

The other issue that gave me trouble was figuring out how far to slide the lock out. I would move it a little and think it had slid out enough, but realize it wasn't and have to try to slide it out more. The screwdrive slips on the plastic tab a lot, making this challenging. Finally I noticed that there is a “locked” and an “unlocked” indicator dot on the side of the FAKRA jack. Don't try to pull the connect off until you see the dot all the way into the unlocked position.

Locked position.

Unlocked position.

Step 5

Slide the isolated/terminated connector on. This was super fast and easy to seat and slide on. I felt it lock into place with a subtle click. I left the original connector to the actual cellular antenna handing off to the side. If you ever want to re-enable OnStar, you slide (no need to unlock!) the isolated connector off and slide the original one back on.

Isolated cellular modem, original connector hanging off to the side.

Step 6

Turn on the car and check for the red light. If you see that it's red you succeeded. You can test that it actually is isolated by attempting to place a call to OnStar. The system “dials” for me but never connected.

Disabled OnStar

Epilogue

OnStar and My Chevrolet are nice for checking the state of charge and charge rates of your Bolt. I discovered that an OBD2 dongle and a reader/writer app can tell you much of the same info. Most of the apps I tried are geared towards gas/diesel cars and required me to import the PIDs for the Bolt and build a custom dashboard. This is not ideal, so I think I might actually build an iOS app to replace the things in My Chevrolet that I care about.

In order to warm or cool the car without having to get in it, you can use the key fob to remote start it by pressing the lock button briefly and then holding the circle arrow icon button for about 5 seconds. This won't work from miles away, but then the trade-off is that someone miles away can't violate your privacy or disable your car.

#hacks #modification #cars #ev #privacy

If you're looking to build a seemingly simple split-view app with a 1-depth sidebar and an n-depth detail view, using List in the sidebar view is a fine choice. But if you do not want the cookie-cutter look and feel List is not your friend. Unfortunately, NavigationSplitView really, really wants you to use List and if you don't use one then don't you dare try to programmatically push more content onto the detail view's navigation stack.

This split view demo from WWDC looks great, but what if your side-bar UI would look better if it were layed out as a grid?

At first glance, dropping the sidebar List view seems to work fine. I will be modifying Majid Jabrayilov's excellent split view code example to demonstrate the limitations (shortcomings? Bugs?) of SwiftUI 4's NavigationSplitView. First let's keep the List-backed sidebar and try to programmatically navigate two levels deep in the detail view:

struct ContentView: View {
    @State private var selectedItem: String?
    @State private var navPath = NavigationPath()
    
    @State private var folders = [
        "All": [
            "Item1",
            "Item2"
        ],
        "Favorites": [
            "Item2"
        ]
    ]
    
    var body: some View {
        NavigationSplitView {
            List(selection: $selectedItem) {
                ForEach(folders["All", default: []], id: \.self) { item in
                    NavigationLink(value: item) {
                        Text(verbatim: item)
                    }
                }
            }
            .navigationTitle("All")
        } detail: {
            NavigationStack(path: $navPath) {
                VStack {
                    if let selectedItem {
                        Button("Button \(selectedItem)") {
                            navPath.append(selectedItem)
                        }
                    } else {
                        Text("Choose an item from the content")
                    }
                }
                .navigationDestination(for: String.self) { text in
                    Text(verbatim: text)
                        .navigationTitle(text)
                }
            }
        }
    }
}

This works great, and if you select the “Button ItemN” button, you will see it programmatically pushes a view onto the detail view's stack.

A 2-level deep detail view on a NavigationSplitView running on an iPhone/compact horizontal size class.

Now let's get rid of that bog-standard List view in the sidebar and replace it with a horizontal grid:

struct ContentView: View {
    @State private var selectedItem: String?
    @State private var navPath = NavigationPath()
    
    @State private var folders = [
        "All": [
            "Item1",
            "Item2"
        ],
        "Favorites": [
            "Item2"
        ]
    ]
    
    let rows = [GridItem(.fixed(30))]
    
    var body: some View {
        NavigationSplitView {
            ScrollView {
                LazyHGrid(rows: rows) {
                    ForEach(folders["All", default: []], id: \.self) { item in
                        NavigationLink(value: item) {
                            Text(verbatim: item)
                        }
                    }
                }
            }
            .navigationTitle("All")
        } detail: {
            NavigationStack(path: $navPath) {
                VStack {
                    if let selectedItem {
                        Button("Button \(selectedItem)") {
                            navPath.append(selectedItem)
                        }
                    } else {
                        Text("Choose an item from the content")
                    }
                }
                .navigationDestination(for: String.self) { text in
                    Text(verbatim: text)
                        .navigationTitle(text)
                }
            }
        }
    }
}

It looks great (🙃). Let's test and then ship it!

A svelte grid layout in the side bar instead of a List . 🔥!

As soon as we select an item though, we get a runtime error:

A NavigationLink is presenting a value of type “String” but there is no matching navigationDestination declaration visible from the location of the link. The link cannot be activated.

Ugh. Let's fix that by providing the sidebar view with a .navigationDestination. We will move the detail view to it's own struct so it can be re-used.

struct ContentView: View {
    @State private var selectedItem: String?
    @State private var navPath = NavigationPath()
    
    @State private var folders = [
        "All": [
            "Item1",
            "Item2"
        ],
        "Favorites": [
            "Item2"
        ]
    ]
    
    let rows = [GridItem(.fixed(30))]
    
    var body: some View {
        NavigationSplitView {
            ScrollView {
                LazyHGrid(rows: rows) {
                    ForEach(folders["All", default: []], id: \.self) { item in
                        NavigationLink(value: item) {
                            Text(verbatim: item)
                        }
                    }
                }
            }
            .navigationDestination(for: String.self) { selection in
                DetailView(navPath: $navPath, selectedItem: selection)
            }
            .navigationTitle("All")
        } detail: {
            NavigationStack(path: $navPath) {
                DetailView(navPath: $navPath, selectedItem: selectedItem)
            }
        }
    }
}

struct DetailView: View {
    @Binding var navPath: NavigationPath
    let selectedItem: String?
    var body: some View {
        VStack {
            if let selectedItem {
                Button("Button \(selectedItem)") {
                    navPath.append(selectedItem)
                }
            } else {
                Text("Choose an item from the content")
            }
        }
        .navigationDestination(for: String.self) { text in
            Text(verbatim: text)
                .navigationTitle(text)
        }
    }
}

When we run this we get to the first level of the detail view, but when we select the “Button ItemN” programmatic navigation button... nothing happens. And this is where it all falls apart.

As of this writing, Jan 1, 2023, on Xcode 14.2 there is no way (that I've found) to programmatically navigate to the second level of the detail view. SwiftUI just doesn't do anything. There are no errors or warnings in the debug console. There is just silence and no navigation.

In fact, the only way to get the detail view to push a second level deep without a List-backed sidebar is to get rid of programmatic navigation on the detail view altogether and replace the button with a NavigationLink:

struct DetailView: View {
    @Binding var navPath: NavigationPath
    let selectedItem: String?
    var body: some View {
        VStack {
            if let selectedItem {
                NavigationLink(value: selectedItem) {
                    Text("NavigationLink \(selectedItem)")
                }
            } else {
                Text("Choose an item from the content")
            }
        }
        .navigationDestination(for: String.self) { text in
            Text(verbatim: text)
                .navigationTitle(text)
        }
    }
}

A navigation split view with a grid-based “sidebar” view and a NavigationLink in the first detail view.

Great! It works now—but only if your user selects the navigation link directly. As with many things in SwiftUI over the last 4 years, this feels like such simple edge case, and yet there's nothing that can be done about it. Our options are either:

1. Host a UISplitViewController in our SwiftUI app and manually handle navigation.
2. Don't programmatically navigate after the first detail view.
3. Use a List for the sidebar view and deal with the visual constraints of a List.

Hopefully this is something the SwiftUI team at Apple can resolve soon. iOS 16 brought a huge quality-of-life improvement to navigation on SwiftUI. It would be nice to see this fixed before iOS 17, but until then if you require a unique-looking UI that navigates sanely, don't let your UIKit skills atrophy just yet. SwiftUI continues to be “close” but not quite “there” yet for another year.

#howto #programming #swiftui #swiftui4 #hacks #workarounds