Finding answers to questions in a text document
At a glance
| Item | Summary |
|---|---|
| Purpose | Locate relevant passages in a document by asking the Bidirectional Encoder Representations from Transformers (BERT) model a question. |
| App architecture | A Swift sample with the source-visible chain AppDelegate → DetailViewController → Document → CoreML APIs. |
| Main patterns | View-controller organization, Delegate or data-source callbacks |
| Project style | 9 scanned source file(s) across Swift, organized around ranked entry, type, and file boundaries. |
Project structure
Source bundle/
├── FindingAnswers/
│ ├── App/
│ │ └── AppDelegate.swift
│ ├── View/
│ │ ├── DetailViewController.swift
│ │ ├── Document.swift
│ │ └── MainViewController.swift
│ └── Model/
│ ├── BERT.swift
│ ├── BERTInput.swift
│ ├── BERTVocabulary.swift
│ ├── TokenizedString.swift
│ └── BERTOutput.swift
├── Configuration/
│ └── SampleCode.xcconfig
└── FindingAnswers.xcodeproj/
├── .xcodesamplecode.plist
└── project.pbxproj
Structure observations
- Architecturally prominent files are ranked from entry points and role-named declarations; resource-only paths are omitted.
- Primary languages: Swift.
- The verified tree contains 7 project/configuration file(s) and 8 source declaration(s).
Overall architecture
flowchart LR
N1["AppDelegate"]
N2["DetailViewController"]
N3["Document"]
N4["CoreML APIs"]
N1 --> N2
N2 --> N3
N3 --> N4
Reference code
FindingAnswers/App/AppDelegate.swift:10 — architecture anchor
@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate, UISplitViewControllerDelegate {
// ...
}Interpretation
The arrows summarize the source-visible entry, role-named types or folders, and framework direction; when nodes come from structural folders, the sequence is a high-level interpretation rather than proof that every adjacent node calls the next. Ownership is claimed only where the next section cites a stored property or assignment. The diagram is intentionally limited to the dominant path into Core ML.
Ownership and state
classDiagram
AppDelegate o-- UIWindow : window
DetailViewController o-- UITextField : questionTextField
DetailViewController o-- UITextView : documentTextView
DetailViewController o-- NSLayoutConstraint : questionTextFieldBottomLayoutConstraint
Ownership evidence
FindingAnswers/App/AppDelegate.swift:13 — stored dependency or nearest verified ownership anchor
@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate, UISplitViewControllerDelegate {
// ...
var window: UIWindow?
// ...
}| Owner | Object or state | Relationship | Mutation authority |
|---|---|---|---|
AppDelegate |
UIWindow (window) |
stores or receives | App/module collaborators |
DetailViewController |
UITextField (questionTextField) |
holds a non-owning reference | The referenced object’s lifecycle is owned elsewhere |
DetailViewController |
UITextView (documentTextView) |
holds a non-owning reference | The referenced object’s lifecycle is owned elsewhere |
DetailViewController |
NSLayoutConstraint (questionTextFieldBottomLayoutConstraint) |
holds a non-owning reference | The referenced object’s lifecycle is owned elsewhere |
Composition arrows indicate a source-visible construction expression or locally owned value state; aggregation means the owner stores or receives a dependency without proving exclusive lifetime ownership.
Class and protocol design
FindingAnswers/App/AppDelegate.swift:11 — representative type boundary
class AppDelegate: UIResponder, UIApplicationDelegate, UISplitViewControllerDelegate {
// ...
}| Type | Responsibility | Depends on or conforms to |
|---|---|---|
AppDelegate |
Receives callback-driven events | UIResponder, UIApplicationDelegate, UISplitViewControllerDelegate |
DetailViewController |
View lifecycle, callbacks, and feature coordination | UIViewController, UITextFieldDelegate, UITextViewDelegate |
Document |
Owns document data or lifecycle behavior | Codable |
MainViewController |
View lifecycle, callbacks, and feature coordination | UITableViewController |
BERT |
Owns feature behavior and collaborator lifecycle | Concrete collaborators/imported frameworks |
BERTInput |
Represents a feature value or composable behavior | Concrete collaborators/imported frameworks |
BERTVocabulary |
Represents a feature value or composable behavior | Concrete collaborators/imported frameworks |
TokenizedString |
Represents a feature value or composable behavior | Concrete collaborators/imported frameworks |
No local protocol conformance is claimed as protocol-oriented design; external framework conformances are listed only as dependencies.
Access control
| Symbol | Access | Verified effect | Likely rationale |
|---|---|---|---|
documentOffset (FindingAnswers/Model/BERTInput.swift:25) |
private |
Use is restricted to the lexical declaration and same-file extensions allowed by Swift. | Inference: keep state mutation or dependency lifetime inside the owning implementation. |
BERTVocabulary (FindingAnswers/Model/BERTVocabulary.swift:36) |
private |
Use is restricted to the lexical declaration and same-file extensions allowed by Swift. | Inference: hide an implementation step that is not part of the collaboration surface. |
lookupDictionary (FindingAnswers/Model/BERTVocabulary.swift:37) |
private |
Use is restricted to the lexical declaration and same-file extensions allowed by Swift. | Inference: keep state mutation or dependency lifetime inside the owning implementation. |
loadVocabulary (FindingAnswers/Model/BERTVocabulary.swift:43) |
private |
Use is restricted to the lexical declaration and same-file extensions allowed by Swift. | Inference: hide an implementation step that is not part of the collaboration surface. |
Reference code
FindingAnswers/Model/BERTInput.swift:25 — representative boundary
private let documentOffset: Int
var documentRange: Range<Int> {
return documentOffset..<documentOffset + document.tokens.count
}Swift declarations without a modifier are internal; explicit private, fileprivate, private(set), public, or open entries above are interpreted by language semantics. Objective-C/C samples instead rely on header and implementation boundaries, which are not equivalent to Swift lexical privacy.
Logic ownership and placement
| Logic | Owning type or file | Placement rationale |
|---|---|---|
| View lifecycle, callbacks, and feature coordination | DetailViewController, MainViewController |
The source’s Controller suffix makes this role explicit. |
| Receives callback-driven events | AppDelegate |
The source’s Delegate suffix makes this role explicit. |
| Owns document data or lifecycle behavior | Document |
The source’s Document suffix makes this role explicit. |
Design patterns
| Pattern | Source evidence | Purpose or tradeoff |
|---|---|---|
| View-controller organization | FindingAnswers/View/DetailViewController.swift:11 |
A controller is the verified coordination boundary; this is MVC-style only where a separate model is present. |
| Delegate or data-source callbacks | FindingAnswers/App/AppDelegate.swift:11 |
Callback protocols invert event delivery back into the sample’s owner. |
Naming conventions
- Types: Controller: DetailViewController, MainViewController; Delegate: AppDelegate; Document: Document.
- Protocols: no local protocol declaration in the scanned source.
- Methods:
application,splitViewController,configureView,viewDidLoad,textFieldShouldReturn,textFieldShouldClear,textViewDidEndEditing,viewWillAppear. - Files:
FindingAnswers/App/AppDelegate.swift,FindingAnswers/View/DetailViewController.swift,FindingAnswers/View/Document.swift,FindingAnswers/View/MainViewController.swift,FindingAnswers/Model/BERT.swift,FindingAnswers/Model/BERTInput.swift.
Architecture takeaways
AppDelegateis the main source-visible entry or composition anchor for this sample.- Framework work reaches CoreML, UIKit, NaturalLanguage through a deliberately small high-level chain; the detailed API graph remains inside the cited implementation files.
- Stored-property evidence identifies lifecycle collaboration; it does not by itself prove exclusive object ownership.
- Access-control conclusions separate verified language visibility from the likely design rationale.
- The source does not justify labeling the design protocol-oriented.
Source map
| Source file | Relevant symbols |
|---|---|
FindingAnswers/App/AppDelegate.swift |
AppDelegate |
FindingAnswers/View/DetailViewController.swift |
DetailViewController |
FindingAnswers/View/Document.swift |
Document |
FindingAnswers/View/MainViewController.swift |
MainViewController |
FindingAnswers/Model/BERT.swift |
BERT |
FindingAnswers/Model/BERTInput.swift |
BERTInput |
FindingAnswers/Model/BERTVocabulary.swift |
BERTVocabulary |
FindingAnswers/Model/TokenizedString.swift |
TokenizedString |
FindingAnswers/Model/BERTOutput.swift |
Feature implementation |