IPhone-Passcode in Xcode einfügen, damit ich mein iPhone nicht für jedes Build entsperren muss?


13

Gibt es eine Möglichkeit, meinen iPhone-Sperrcode in Xcode einzufügen, damit ich mein iPhone nicht für jedes Build entsperren muss?

Es wird wirklich frustrierend, dass ich mein iPhone vor jedem Build physisch entsperren muss.

Ich weiß, für die Entwicklung auf Android können Sie das Gerät in den Dev-Modus versetzen, was den Ruhezustand des Geräts einschränkt.

Antworten:


7

Könnte jeder dies bitte als Fehler melden ?

So wie es aussieht, können Sie es entweder ertragen oder, viel schlimmer, die Sperre deaktivieren. Keine Option ist gut.

Wenn sich das iOS-Gerät im Entwicklermodus befindet und mit einer aktiven Xcode-Instanz verbunden ist, sollte Xcode das Telefon entsperrt lassen können.

Auf diese Weise können Sie die Sperre nicht nur aktiviert lassen, sondern sie wird sofort wieder aktiviert, wenn Sie die Verbindung trennen.


1
Warum sollte das ein Bug sein? Es ist einfach mit Absicht entworfen. Sie möchten, dass jemand in der Lage ist, jede gewünschte App auf Ihr Telefon herunterzuladen, und zwar mit der Chance, dass sie gestohlen und wie sie ist "zurückgegeben" wird. Ganz klar ein Sicherheitsmerkmal. Es ist eine so mühsame Aufgabe, wenn Sie das Telefon so einstellen, dass es niemals automatisch gesperrt wird. Es gibt mehrere Möglichkeiten, um dieses "Problem" zu umgehen, Apple kann jedoch keine Faulheit für Benutzerenden einplanen. & ja, ich bin ein Entwickler und sehr aktiv auf SO
soulshined

1
Sie stellen zunächst fest, dass die automatische Sperre eine gute Funktion ist, und sagen dann, wie einfach das Ausschalten ist. Diese Aussagen stimmen nicht überein. Autolock deaktivieren ist im Allgemeinen eine schlechte Idee, aber notwendig während der Entwicklung. Eine Funktion, die dies automatisch tut, während sie in Xcode eingesteckt ist, ist eine sehr gute Idee, um zu verhindern, dass versehentlich Personen die Funktion deaktivieren, die Sie für gut halten.
Maury Markowitz

Sie haben meine Worte falsch interpretiert, um sie Ihren Argumenten anzupassen. Ich habe nie gute Eigenschaften gesagt. Besagtes Sicherheitsmerkmal. Und ich habe nie gesagt, einfach abzuschalten. Sie sagten, dies sei übertrieben. Egal, ich bin kein 5-jähriger und möchte dich auch nicht als einen behandeln. Ich sage nur meine Meinung und Perspektive. Es dreht sich alles um Ihre Entwicklungspräferenzen. Wenn Sie es sich zur Gewohnheit machen, die automatische Sperre auszuschalten, und es sich dann zur Gewohnheit machen, sie einmal einzuschalten, wird sie zur zweiten Natur. Ich fühle mich einfach übertrieben in der Situation und den Lösungen. Ich würde es nicht einen Bug nennen, mein Hauptargument, nur eine Feature-Anfrage. Prost
Soulshined

@soulshined, eine automatische Entsperrfunktion würde erfordern, dass das iOS-Gerät dem Computer zuerst vertraut (die übliche Vertrauensgenehmigung, die einmal erfolgt), sodass niemand ohne Ihren Computer eine App darauf herunterladen kann. Da Ihr Computer in erster Linie passwortgeschützt sein sollte, kann ich keine Sicherheitsprobleme erkennen. Wenn jemand auf Ihren Computer und Ihr Kennwort Zugriff hat, treten bei Ihnen weitaus größere Probleme auf. Darüber hinaus ist das Deaktivieren der automatischen Sperrfunktion ein viel größeres Sicherheitsproblem als ein vertrauenswürdiger Computer, der ein Gerät automatisch entsperrt.
Arda

2

Sie können verhindern, dass das Gerät in den Einstellungen → Allgemein → Automatische Sperre → Nie in den Ruhezustand wechselt . Dies bedeutet, dass das Gerät entsperrt bleibt und Sie es nicht entsperren müssen. Da ich einen Jailbreak habe, wird dieser automatisch festgelegt, wenn mein Gerät mit einem Computer verbunden ist, auf dem Xcode ausgeführt wird. Eine manuelle Änderung dieser Einstellung funktioniert jedoch auch einwandfrei.

Alternativ können Sie Einstellungen → Passcode → Passcode anfordern auf einen längeren Zeitraum festlegen, sodass Ihr Passcode nicht erforderlich ist, wenn Sie ihn entsperren müssen. Vergessen Sie nicht, diese Einstellung nach Abschluss der Entwicklung wieder auf die ursprüngliche Einstellung zurückzusetzen.


Es scheint, Auto-Lock -> Nie ist keine Option mehr in ios 9.
Rätsel

1

Soweit ich weiß, ist das nicht möglich . Die einzig mögliche Lösung wäre natürlich, den Passcode des iPhones während Ihrer Programmiersitzungen zu deaktivieren.


1

Dies ist eine Problemumgehung.

In AppDelegate.swiftfügen Sie diesen Code

class AppDelegate: UIApplicationDelegate {

let isDebug: Bool = {
        var isDebug = false
        func setDebug() -> Bool {
            isDebug = true
            return true
        }
        assert(setDebug())
        return isDebug
    }()

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {

    // for development only
    // to make iPhone screen always on when developing app. 
    // should be removed when app is released

    if isDebug {
        print("DEBUG MODE")
        UIApplication.shared.isIdleTimerDisabled = true
    }

    return true
  }

}

Dies betrifft nur das Telefon, während die App ausgeführt wird. Wenn Sie die App beenden und eine Weile daran arbeiten, wird der Bildschirm möglicherweise gesperrt, bevor Sie sie das nächste Mal ausführen.
Tom Harrington

0

Die wirkliche Antwort ist, dass Sie derzeit einen Jailbreak benötigen, um dies zu tun, wie in @grgarside angedeutet.

Verwenden Sie Activator (von Cydia installieren, falls Sie es noch nicht haben) und legen Sie die Aktion für Anywhere -> Connected (Power)die Aktion fest, die die automatische Sperre deaktiviert. Machen Sie das Gegenteil (Auto-Lock aktivieren) für Disconnected (Power).


1
Wir sollten keinen Jailbreak haben, um dies zu tun. Bitte rufen Sie den Apple Bug Reporter auf und melden Sie ihn. Wenn genug von uns das tun, werden sie das beheben.
Maury Markowitz

0

In Xcode 7.3 müssen Sie Ihr Gerät anscheinend nur beim ersten Build entsperren. Danach bleibt Ihr Gerät entsperrt, bis Sie es vom Computer trennen oder die zu testende App beenden.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.